[brussels-dev] [smf-discuss] alternative to driver.conf(4)?

[Liane Praza]

Jordan Brown wrote:
> Garrett D'Amore wrote:
>>> Why isn't the right answer to run an application that reads config 
>>> files (or reads SMF properties) and issues ioctls to get the data into 
>>> the driver?
>> Well, we can do that, but the problem is making sure that the above 
>> operation is done at the appropriate time.  I need to have those values, 
>> in some cases, at driver attach() time.  By the time an application 
>> comes around to populate it, it may be too late.
> 
> I can believe that's true for some devices, but not many.  Changing it 
> might require a driver redesign so that the device is relatively inert 
> until the config application runs, but such a redesign should be on the 
> table.  (I mean, if we're going to design something, maybe the right 
> thing to design is the driver.)

If, instead, you go with Mike's suggestion (which is always the way I've 
thought about this problem), and determine a way to 'tag' the 
configuration as driver/required-by-kernel, SMF itself can take care of 
marshaling the configuration into a kernel-readable format.  (i.e. a 
file of nvpairs.)

For bonus points, that format can be included in the boot archive, so 
that necessary configuration for early-boot-attached drivers is available.

Mike's two design questions are key to attacking this problem.  I'd stay 
away from constraining driver/kernel configuration to be read only by a 
userland application.

liane