Brussels is providing legacy support for ndd by fielding the
ND_SET/ND_GET ioctls in the shim dld layer. So attempts
to use the ndd calls will still work, post-brussels,
though the drivers will be liberated of the ugly cut/pasted,
undocumented calls to ndd interfaces like nd_getset()
At our last iteam meeting, we were discussing ways of
addressing driver.conf(4) similarly. Let's say that some
property <foo> is now supported as a Brussels property
(a classic example would be foo = default_mtu for
Jumbo Frames). Three options were suggested
1. provide support via scripts (or via code in dladm/dladmd)
that parses driver.conf on reboot, or when update_drv is run,
and converts the input to dladm configuration input. This
method has several drawbacks- the biggest one is that
certain drivers won't be able to access the most
current administrative state via the dladm repository until
he conversion-procedure is run. Implementation of this method
is also likely to be complex, and therefore error-prone.
2. clearly document that <foo> is no longer supported via driver.conf
and that dladm should be used instead. Provide scripts for
each Brussels-ized driver for users to run, to convert existing
driver.conf syntax to linkprop.conf syntax.
It's important to get the documentation right, for this option.
The driver's 7D man page will clearly have to be documented to
contain the dladm invocation for setting <foo>, but it's not
clear (to me, at least) where we should document the end of support
for driver.conf setting of <foo>- the problem is that
current driver.conf keywords are themselves not documented
in a predictable way. Some drivers (qfe, dmfe, eri) have a precedence
of publishing Platform notes. This may be the option to adopt.
Also, adopting this method alone would restrict us from backporting
so s10ux.
3. As we convert each driver, we provide some backward compatibility
crutches, by doing
if (mac_prop_get(/* .. */) || ddi_prop_get(<foo>, /* ... */) {
/*
* set <foo>; maybe log a message that the user
* should be using dladm instead of driver.conf
* to set <foo>.
*/
}
This method leaves us with potentially redundant calls to
ddi_prop_get(), but does match the method adopted by
PSARC 2003/344, where attempts to set things like <if>:ip_forwarding
via ndd results in a WARNING message. (For the curious, the message
itself is something like
"WARNING: The <if>:ip*_forwarding ndd variables are obsolete and
may be removed in a future release of Solaris. Use ifconfig(1M) to
manipulate the forwarding status of an interface.")
My own preference would be for a combination of #2 and #3. For Nevada,
#2 alone is the cleanest approach. Votes? Other ideas?
--Sowmini
