On (08/17/07 08:53), Garrett D'Amore wrote: > Yes, Option #4. > > Have mac_prop_get() lookup the property in the devinfo tree > (ddi_prop_get()) on behalf of the driver if a value is not provided by > Brussels. (The Brussels database/config files should override > driver.conf tunables.) > > The lookup should be optional (perhaps triggered by a flag to > mac_prop_get()), should use the same property name, and should be able > to parse the property for the driver. : > As part of this, driver.conf tunables that are part of Brussels may get > renamed (in the driver.conf file).
But that still leaves a "user-surprise" lurking, where the user thinks they set "foo" via driver.conf, but they should have set "bar". > The upgrade program may need to be > changed to carry forward manual edits... though my gut reaction is that > driver.conf tunings are not carried forward on upgrade. remember that driver.conf is shipped read-only (see CR 6396173, 6430731). So maybe #2 is the best way to inflict this pain. And we could document the new name using the sample driver.conf that we ship (that seems to be the current procedure for documenting it anwyay- via comments in the shipped template). However, your suggestion (looking up ddi_prop as a last resort) would address the diskless boot case as a side-effect. > Ultimately, I'd like to gradually move drivers/system admins away from > driver.conf for tuning values. But this will take time. --Sowmini
