[EMAIL PROTECTED] wrote:
On (06/22/07 10:26), Garrett D'Amore wrote:
Why not have mac_prop_lookup go to the DDI properties on behalf of the
driver? (In other words, instead of going up to some daemon, if the daemon
isn't present, just use the driver.conf properties.)
What I'm getting at is, this detail, can be hidden behind the
mac_prop_lookup() API.
mac_prop_lookup does not go to the daemon in the current design.
At the start of attach (or mac_start() - see
http://www.opensolaris.org/jive/thread.jspa?threadID=33043&tstart=0),
the handshake between kernel and daemon is done to load up the property
list in the kernel into a "mac_prop_t" list. After that, when the
driver does a mac_prop_lookup(), the property is retrieved from the
kernels mac_prop_t list.
The ddi properties are retrieved by doing file processing in hwc_parse()
(when it is called from i_ddi_load_drvconf). So unless we make this
code parse dladm.conf (which has its own problems, not the least of
which is that dladm.conf syntax is Private, and can be XML-ed, not to
mention that we don't want to be doing some bulky string/file processing
in the kernel) and load up the mac_prop_t list, the driver code (or the
underlying mac_prop_lookup) will have to call ddi_prop_lookup to get at
the property.
But the more fundamental issue is that we still end up with this
reliance on driver.conf.
Yeah, I'm not too thrilled about this.
Configuration of properties for diskless boot is a major PITA. I had a
different solution for this, which actually _did_ involve parsing
configuration files (name-value lists) in the kernel. That was how I
solved it for Tadpole.
Btw, I also like Darren's approach of pushing a copy of the
properties to
the driver.conf (using driver.conf as a secondary store), but I
recognize
that this has its own set of problems. (Like the fact that
/kernel/drv/xxx.conf might not be on a writable filesystem.)
There are others. we now have the unpleasant task of translating something
like "bge0 default_mtu=9000" to some ugly string that has pci path names
in it. And dladm gets to figure out the shibboleth that each
driver uses for some particular tunable.
No, don't try to have differences for each driver. Just use one common
name for each ddi property. :-) It will be up to administrators (or
upgrade scripts!) to adapt to the new names/syntax. :-)
Which leads me back to the point raised in early discussions that it
might not make sense to convert every single property to Brussels, esp.
if the property really cannot be modified on the fly, but is so closely
related to attach that it needs all its input at the start of attach.
i.e., don't reinvent update_drv, if update_drv cannot be avoided.
I would agree that there may be some properties that cannot easily be
converted.
But I think there are also properties that _can_ be provided by
Brussels, but which some drivers may not easily be converted.
--Sowmini
_______________________________________________
networking-discuss mailing list
[email protected]
