[brussels-dev] NDD compatibility shim in gldv3

[sowmini.varadhan at sun.com]

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?

--Sowmini