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. > 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. 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. --Sowmini
