On Fri, 2007-08-17 at 09:52 -0400, sowmini.varadhan at sun.com wrote:
> 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?
Yes, Option #4.
Have mac_prop_get() lookup the property in the devinfo tree
(ddi_prop_get()) on behalf of the driver if a value is not provided by
Brussels. (The Brussels database/config files should override
driver.conf tunables.)
The lookup should be optional (perhaps triggered by a flag to
mac_prop_get()), should use the same property name, and should be able
to parse the property for the driver.
There are drivers that have properties in two formats:
1) standard property per instance using the parent node. This is the
"documented" way of creating a property via driver.conf, but it is a
painful.
2) comma-separate list using a "global" property, where each item in the
list corresponds to an instance. I find this to be truly ugly, but it
is intended to make it easier for sysadmins than going thru the pain of
figuring out the parent node.
We'd have to choose whether to support only the first format, or also do
the second format.
As part of this, driver.conf tunables that are part of Brussels may get
renamed (in the driver.conf file). The upgrade program may need to be
changed to carry forward manual edits... though my gut reaction is that
driver.conf tunings are not carried forward on upgrade.
Ultimately, I'd like to gradually move drivers/system admins away from
driver.conf for tuning values. But this will take time.
-- Garrett
>
> --Sowmini
>
> _______________________________________________
> brussels-dev mailing list
> brussels-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/brussels-dev
