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 _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
