Sebastien Roy wrote: > sagun shakya wrote: >> I've uploaded the PSARC fasttrack materials to the clearview >> website. Feedback/comments are welcome. >> >> PSARC fasttrack proposal: >> http://www.opensolaris.org/os/project/clearview/libdlpi/libdlpi-psarc_addendum.txt >> > > > A few comments: > > * the interface classification for the new functions needs to be made > explicit. > I've fixed this. > * I think some background is needed about what the types in > <net/if_types.h> and <netinet/arp.h> are, what they're used for, and why > one might want to translate a DLPI MAC-type to one of these types > using these functions. I'm specifically concerned about why we need > dlpi_iftype(), since I don't think anything except for the Solaris > kernel uses types from <net/if_types.h>... I could be wrong, so some > clarification would be nice. > > * I'm curious why we think that dlpi_iftype() will be more useful than > a function that does the reverse if we have no consumers for the > interface to begin with. What is the justification for this function, > and how do we not have the same justification for its reverse > function? For dlpi_arptype(), it's more obvious since there's a > consumer. > There aren't any user right now. I'll add more clarification > * What does the 64-bit libdladm work have to do with the DLPI API? I > know that we were already in libuuid and removing unnecessary code, > but I don't see the architectural link with the title of this case > since the change is to libdladm. If it's not architecturally related > and doesn't involve public interfaces, then it might be better suited > for a separate (perhaps self-review/approved-automatic) case. Any > other opinions on this? There isn't an architectural link with the DLPI API. I agree that a separate case is appropriate.
-sagun -- Sagun Shakya 781.442.7344/ X27344 sagun.shakya at sun.com
