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
