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 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. * 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? Thanks, -Seb
