On (06/22/07 08:37), Garrett D'Amore wrote: > > The upshot of this, is that I think it makes sense to consider the > following approach. Please let me know your thoughts: > > Consider a brussels strategy of "importing" initial values from DDI > properties. (I.e. look first there for initial values, then look > in the Brussels database which can override the driver.conf values.) > > Consider a method for drivers to request that Brussels "pass-thru" a > request for a private property; in other words, first look in the > Brussels property database, and then if not found there, look in the > DDI property list.
Both of these are needed (see section 5.0.5), and will be done in Brussels - the first one can be achieved at dladmd startup, and the second, for example, by setting up update_drv to trigger the update of the dladm.conf file, [#] but.. the problem that Erik is alluding to, is not so much "how to get dladmd to keep abreast of changes to driver.conf", but rather "there may be no dladmd when the driver attaches in a diskless boot env. So how to get the brussels properties?" In the latter scenario, the driver code itself will have to be written to do both the ddi_prop_lookup as well as the mac_prop_lookup. > Generally speaking, driver.conf properties don't change on the fly, so this > initial import need only be done on first driver attach. right, and we don't want to require the driver to check both the ddi_prop_t list as well as the mac_prop_t list for those properties. --Sowmini [#] the second can actually be done rather elegantly when the Clearview proposal of having smf scripts to start/stop the link is implemented: see http://www.opensolaris.org/jive/thread.jspa?threadID=31315&tstart=0. In that scenario, driver.conf -> dladm.conf translation becomes part of the startup process.
