sowmini.varadhan at sun.com wrote:
> I just put out a preliminary prototype webrev for achieving
> NDD compat through shims in the mac layer at
>
> http://cr.opensolaris.org/~sowmini/nddcompat/
>
> the basic idea is that the ND_SET and ND_GET ioctls will be
> trapped in the mac layer and dispatched as mc_setprop and
> mc_getprop calls.
>
> In the webrev, when the driver calls mac_register(),
> it also registers its NDD tunables (see the call to bge_nd_init()
> in bge_ndd.c) at which time it passes a (void *) pointer with
> information that it can use when called back, to set/get values.
>
> Then, when the ND_SET/ND_GET ioctl is intercepted in the mac
> layer, mac_ndd_{set,get}_ioctl() (in the new file, mac_ndd.c)
> looks up the registered entries for that driver, and if a match
> is found, invokes the mc_setprop/mc_getprop with property number
> set to DLD_PROP_NDD_LEGACY.
>
> There's an additional level of optimization possible, that
> I'm toying with. Since most ndd properties (not counting
> the outliers such as those related to flow-control, or
> those that have - and _ interchanged) are now public properties.
> So, the mac layer can map the ndd name passed with the ND_SET/ND_GET
> ioctl to a public property number, and just invoke the public
> property itself. I've demo-ed this in the webrev for the "adv_autoneg_cap"
> property (leaving out the rest for the sake of readability).
>
> Doing this mapping is cleaner, because a well-behaved driver
> (one that has no outliers) will not need to register anything,
> and can just gut out any ndd code it has today.
>
> But doing this mapping is also a little evil- if I were to write
> a clean driver "foo" today, that only uses Brussels interfaces,
> I would find that I could use both ndd and dladm to set the
> MII props even though I have no intention of supporting ndd
> configuration. In other words, this silently perpetuates the
> usage of ndd where none is intended. So is this serious enough
> to disqualify the ndd <-> "public property" mapping optimization?
>
First off, a big *thank-you!* for doing this.
Secondly, as far as ndd usage goes. I am of the strong opinion that
there is huge benefit in doing this mapping. We cannot remove ndd
usage, now, or for the foreseeable future. (I guess maybe in a Solaris
12 release, but as there is no schedule for a Solaris 11 yet, I am
thinking I may be dead before Solaris 12 ships. :-/
*HOWEVER*, I agree that we want to discourage use of ndd for device
driver tuning. THEREFORE, I recommend the following strategies:
1) go ahead and do the mapping
2) mapping code should log a message to syslog when it finds this being
used ... e.g. "please don't use ndd anymore".
3) alternatively, ndd(1M) could, when it finds that it is being used to
perform tuning on Brussels drivers, and when its stdout is a tty, print
to stderr a similar warning: ndd is deprecated for this usage, please
use dladm instead!
4) remove all references to ndd in driver man pages and docs as they are
converted to Brussels
5) change the Solaris tuning docs to refer to dladm
6) aggressively convert the remaining drivers in ON
Furthermore, since Nemo isn't public yet (and hence Nemo drivers can't
make use of Brussels), we really need dladm(1M) to be useful for legacy
ndd-style drivers as well. At least until Nemo is public and GLDv2 can
be marked Obsolete.
For my part, I'm willing to handle #6 on a significant number of drivers.
For now, I'll go ahead and review the code. :-)
-- Garrett
> --Sowmini
>
> _______________________________________________
> brussels-dev mailing list
> brussels-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/brussels-dev
>
