James Carlson wrote: > Joachim Worringen writes: >> Peter Memishian wrote: >>> > Suggestion on existing solutions still welcome... >>> >>> Can you elaborate on why you need to do this within the kernel? >>> >> Good point. I'm porting a driver (socket module) from Linux to Solaris. >> >> The rationale to do it within the driver is that we need to know if >> interfaces are removed, added or have their address changed. > > Can you pop up a level from that? Why would a driver care about this > information? If this is something like one of those InfiniBand shim > layers (which trick applications into using IB when the app thinks > it's using TCP/IP), then you'll probably need to integrate pretty > tightly with IP itself.
Yes, it's for this purpose (although not IB, but our SCI and DX remote-shared-memory interconnects). > Even then, I think such things are of questionable design. It sure > would be nice if new transport layers became first-class citizens > rather than piggybacking off TCP/IP. This is a valid opinion; we already discussed this about one year ago when the "pluggable socket module" project (now "volo") was about to start. One (the?) major goal of this project is to allow alternate transport layers be used via the standard sockets API. The missing adaption of "better" APIs like uDAPL shows why this approach is necessary, including IP addressing schemes. >> On Linux, >> this can be done via some sort of hook (inetaddr_notifier_func_t), and >> we then change our internal structures accordingly. > > There are similar things in the 'neti' interfaces used by IP Filter. > > If you go with sockets, then a routing socket (PF_ROUTE) will tell you > about interface events. Thanks, we'll see how we can use this. This is not our primary problem, though. >> Which brings me to the next question (now that the initial enumeration >> works within the Solaris kernel): how can such a >> callback-on-interface-event be implemented on Solaris? > > See neti and the existing IP Filter code ... but you'd likely want to > be in bed with the IP implementation itself to accomplish this. Doing > it as a separate driver sounds dicey to me, as we don't have stable > interfaces for it. We are not eager to use undocumented interfaces... Joachim -- Joachim Worringen, Software Architect, Dolphin Interconnect Solutions phone ++49/(0)228/324 08 17 - http://www.dolphinics.com _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
