Sebastien Roy wrote: > On 03/18/11 07:40 AM, James Carlson wrote: >> Anyway, I ran out of steam on this. With 20/20 hindsight, I should have >> just implemented the right thing and ignored the nonsense going on at >> that almost perfectly useless standards group -- and the nearly certain >> static I would have gotten from our internal review boards. Ignoring a >> standards body is no small thing, but sometimes necessary. And I admit >> I completely chickened out. > > Likewise, I remember those discussions and have the same recollection. > The context is a bit different now, as we've defined a number of private > DLPI datalink-types in order to seamlessly implement other "datalinks" > such as IP tunnels without having to argue DLPI philosophy with other > vendors (see DL_IPV4 and DL_IPv6). A DL_PPP could simply be defined in > that private range.
The sticky part, as I recall, is that DLPI isn't a binary interface, but rather a source one. It's defined by the compile-time symbols, data structures, and the message syntax and semantics. In other words, I don't think it would have been completely kosher to add new DL_* symbols to sys/dlpi.h unless they were hidden away when you're compiling in a standards-conforming environment. (Well, that is, if anyone cares about such things.) For what it's worth, I completely agree with the direction taken here, and I think the newish DL_IPV* symbols are a very good thing. The point, though, is that there likely is no such thing as a "range." There *is* a range, though, for the datalink types used in the snoop header, and these are documented in an Informational RFC. That should probably also be updated ... >> If there's someone now with the time to make DL_PPP come to life, then >> please do change it. > > This could be done in two stages. Making sppp use DL_PPP (and making > changes to consumers of the driver to understand DL_PPP) could be done > independently from migrating the driver to GLDv3. Yes; completely agreed. I should have made that clearer. What I was trying to point out was that the last time I looked into this issue or talked to someone about it, the rest of the folks in Solaris Networking seemed to think that the GLDv3 thing was way more important than the DLPI datalink type, and so if any touching was to be done, it should have included GLDv3 as part of the effort. I didn't really agree ... but I suspect there were few involved who'd really read the PPP code closely. :-/ > I say that because > the cost of the former is likely less than the latter, and the latter > isn't necessarily required to address the immediate issues brought up > here. True. > The GLDv3 work goes beyond simply creating a PPP MAC-type plugin > for the MAC layer. The use of STREAMS is heavily baked in to the kernel > PPP implementation and the plumbing of PPP links, and investigation > needs to be done to see how much of the use of STREAMS can be replaced > or adapted to interact cleanly with GLDv3. My opinion (not having > scoped the work in detail) is that this would be a small project. I doubt it'd be easy. The two issues I know of are the PPP-to-IP connection, which currently involves an on-demand allocation of devices, pretty much unlike Ethernet, but possibly somewhat like tunnels; and the PPP-to-async connection, which really must use STREAMS and which can be established and torn down without touching the connection to IP in order to support demand dialing. And because you've got this lower layer that must use STREAMS, there are ioctls that enter through the top and are reflected out the bottom in order to get hardware statistics and control the operation of AHDLC. Somehow, if an ioctl comes in through GLDv3, it'll need to be sent out via STREAMS on the serial side. That probably means building in a stream head for sppp. Or rewriting all of the bundled and unbundled serial drivers to use something other than STREAMS. Or restricting the ioctls to cases where the top side is open via STREAMS, and somehow giving the PPP code direct access to the legacy STREAMS-handling part of GLD. STREAMS was easier and more consistent, at least in some ways. ;-} -- James Carlson 42.703N 71.076W <carls...@workingcode.com> _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
