[ofa-general] question regarding umad_recv

[Sasha Khapyorsky]

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. I think it was useful method when poll()
and select() on multiple file descriptors was needed and somebody can
have it in a code.

> > > 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?

> If we were
> starting today, would you say the same thing ?

Most likely not. :)

Sasha