sowmini.varadhan at sun.com wrote:
> 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.
>
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.
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.)
-- Garrett
>
>> 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.
>
