[EMAIL PROTECTED] wrote:
On (06/20/07 11:21), Erik Nordmark wrote:
Brussels properties will be available when the driver attaches: early on
in the xxx_attach routine, each converted driver will invoke dladmd with a
door_upcall and persistent properties will be loaded up in the kernel
for the driver as part of the door_upcall. So this should work equivalent
to the driver.conf behavior for diskless client.
For diskless boot the driver attached long before init runs, hence there is
no daemon to talk to.
Erik
This would be an issue for those {driver, property} combinations where
the driver has been inflexibly written to expect all properties to be
available at the start of attach. FoR the cases where a property is being
converted to the Brussels framework, we are also cleaning up the driver
code so that the property can accomodate changes more flexibly, e.g.,
for the case of default_mtu/jumbo-frames, re-organize the driver code
so that the property can be updated on unplumbed (but attached) driver.
I do acknowledge that it would be ideal to have something that is exactly
equivalent to driver.conf (and we are investigating this), but the
side-effect of flexible code brings its own benefits.
I think elimination of ddi properties altogether may be unrealistic.
*) there are those drivers with properties that must be set at boot. in
some cases, its not entirely practical (or just plain not worthwhile) to
reorganize them to be dynamically tunable. (Hopefully cases of this are
rare.)
*) In some cases, the drivers use ddi properties (not necessarily
driver.conf) as a means of communication between the system firmware and
the OS. (See mac-address and local-mac-address, etc.) So ddi
properties are still required.
*) conversion of drivers that use driver.conf to something else may
prove to be quite daunting
*) driver.conf remains the way to configure properties for other,
non-NIC, devices.
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.
Generally speaking, driver.conf properties don't change on the fly, so
this initial import need only be done on first driver attach.
-- Garrett
--Sowmini
_______________________________________________
networking-discuss mailing list
[EMAIL PROTECTED]
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
