> One can take the (quite reasonable, IMO) view that kstats, ndd tunables, > and even driver.conf properties all are just "properties" of one form or > another, some writeable, and some not. > > So what I've been trying to drive Brussels toward is providing a > *single* API in drivers (setprop/getprop) for doing all this, and let > Brussels do details like supporting kstat, legacy NDD ioctls, and the > newer dladm support ... all on top of the setprop/getprop API. > > (Note at this point I'm talking about the driver/kernel bits of > Brussels.... the userland access to certain properties via dladm is just > a bonus, IMO. :-)
I regard the dladm interface and associated programmatic API as the *core* goal of the project, not a bonus. In particular, the fact that an admin has to use a different technique to set jumbograms for every driver is a serious usability issue -- and (more critically) precludes the development of layered utilities. Fixing that is paramount; driver simplification is also great (and related since simplicity and uniformity are complementary), but a secondary consideration. Of course, if we can do that along the way with minimal effort, I'm all for it. But that needs to be scoped out by the project team. -- meem _______________________________________________ networking-discuss mailing list [email protected]
