[ofa-general] question regarding umad_recv

[Hal Rosenstock]

On Mon, 2007-10-15 at 21:51 +0200, Sasha Khapyorsky wrote:
> On 11:35 Mon 15 Oct     , Hal Rosenstock wrote:
> > > 
> > > I changed this only in umad.c files (to make it clear for internal
> > > implementation reviewers) and saved it as 'portid' in the header where
> > > API is described - an user should not care what internal meaning of
> > > portid is. For getting fd explicitly there is umad_get_fd(portid)
> > > method.
> > 
> > Which could be eliminated as redundant; not sure anything is using this
> > API.
> 
> Then this would be API change.

True.

>  I think it was useful method when poll()
> and select() on multiple file descriptors was needed and somebody can
> have it in a code.

Good point. Wasn't thinking of that use model.

> > > > Don't a number of them indicate int portid as an input parameter (and
> > > > this should now be int fd) ? Just grep for portid in those man pages...
> > > 
> > > Don't think we want to make the internal in its nature "portid = fd
> > > feature" to be part of the public API. 'portid' is fine IMO because it
> > > doesn't mean a lot - just "0 or an unique positive value...", pretty
> > > suitable for public API.
> > 
> > portid gives a level of abstraction but is it needed ?
> 
> Only in sense of keeping the same API meaning.
> 
> Seems you don't think it is very critical, cannot say I disagree so much.
> Hmm, let's change portid -> fd and depreciate umad_get_fd() after OFED?

I was just wondering (looking at the change as to how far should it go).
Seems like what you propose is fine. We can see what additional feedback
there is. No need to change after OFED 1.3.

> > If we were
> > starting today, would you say the same thing ?
> 
> Most likely not. :)

That's what I thought might be the case :) I was just wondering if this
was the "legacy" code motivation and it seems that this is what is the
primary factor in keeping it portid. I'm fine with that.

-- Hal

> Sasha
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general