sowmini.varadhan at sun.com 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 > >
