[EMAIL PROTECTED] 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.
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
