Peter Memishian wrote:
> 1) Currently GLDv3 exports DLPI style 2 nodes, as does GLDv2. I think
> this adds complexity, and ultimately I think everyone would be better
> served if we could eliminate this. I'd like to propose EOF'ing the
> export of DLPI style 2 from GLDv3 (and incidentally from softmac.)
I think netboot still relies on DLPI style 2 today. I'm not sure what
else might be blown out of the water by this. Further, libdlpi isolates
consumers from this concern and dld/softmac isolate providers from this
concern, so I'm not sure what critical code is impacted by style 2
support.
Netboot (legacy netboot, as opposed to DHCP) is on the way out. The
little bit of code in genunix could easily be changed to use DLPI style
1, if the NICs all export DLPI style 1 nodes.
> 2) Support for DLPI based ethernet device drivers. Right now we have
> one major hold out (ce), which we *could* fix, but even if we don't
> *remove* the DLPI interfaces in softmac, once GLDv3 becomes a public
> interface, I think we ought to make the legacy GLDv2 and DLPI methods as
> Obsolete. Eventually it might even be possible to remove them, either
> by updating the existing drivers, or by EOF'ing the final hold outs.
See previous discussion: if we update softmac to just be a shim (again,
this was the original design), then supporting these legacy drivers seems
very low-cost. Further, if we have to continue to support DLPI for
non-Ethernet (e.g., PPP) then what exactly does removing this simplify?
Eventually removing the complexity of softmac itself! At least for
Ethernet. (softmac doesn't do *anything* for PPP or other non-Ethernet
links.)
> Do these ideas sound incredibly heretical to anyone?
I don't find it heretical but I see limited value as-scoped and the
risk of pain and breakage.
I'm deep in this code now... and I *do* see value in cleaning this stuff
up, at some point.
- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
