Peter Memishian wrote:
> 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.
See the "IMO" above. :-) I realize that my view is different, since I'm
typically seeing things from the bottom (driver) up, rather than the top
(sysadmin) down.
At some level, if the ndd parameters were _consistent_, then we wouldn't
need dladm, except to help deal with persistence of these parameters.
Not that I'm trying to devalue the dladm portion mind you... I think
there is great value in having a clean, consistent administrative
interface as well. (And the fact that dladm helps with other things,
like secure objects for wifi, and additional driver operations like wifi
scanning, as well as future directions for crossbow and clearview,
provide a lot more justification for dladm.)
But I would like the team to consider both ends (top and bottom) as
_primary_ goals, rather than giving the cleanups in the driver a
2nd-level priority, particularly since I believe that cleaning up the
associated mess at the bottom end of the stack can be done without much
additional effort.
And, as you say, the goals are highly complementary.
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
