On Fri, 2006-09-22 at 22:22 -0700, Richard L. Hamilton wrote: > How does this compare to ways of doing link-level access on other platforms > (either STREAMS or sockets model)?
The libdlpi API is unique to Solaris, but DLPI itself as a message-based link-layer API is not (see AIX and HPUX). The goal of this project, however, is to isolate Solaris DLPI consumers (inside and outside of the ON consolidation) from the complexities of the message-based interaction required of the DLPI standard and from Solaris-specific implementation details. The existing libdlpi library on Solaris already accomplished this to some degree for ON consumers (it was Consolidation Private), and making this library API public for non-ON consumers is part what this work is about. It's not about getting rid of libdlpi in favor of something more portable, although having a more portable link-layer API is certainly a fine idea. > That is, if I were porting link-level application code, this might simplify > the Solaris-specific implementation, but it wouldn't eliminate the need for > it, would it? No, it wouldn't. The loftier goal of providing a OS-neutral API for link-layer access is outside the scope of this project. > Sure would be nice to have true AF_LINK socket support (assuming that's > the most popular version of link-level access)... It would be interesting to investigate this as a potential project, and I'm not sure anyone has done that. I certainly don't think this would be a trivial effort. > Now, perhaps for mere listening, existing freeware such as libpcap already > does reasonably well at hiding platform differences. But that doesn't handle > sending, let alone configuring, does it? No, it does not. > Seems to me there ought to be something, whether AF_LINK sockets or > a higher level abstraction, that does all those things across multiple > platforms. It sounds like you're volunteering. Would you like to start such a project? ;-) Note that this libdlpi library would make writing and maintaining such an API on Solaris a much easier proposition than having to interact with DLPI as a message-based mechanism directly. -Seb _______________________________________________ networking-discuss mailing list [email protected]
