sowmini.varadhan at sun.com 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
> networking-discuss at opensolaris.org
>
