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
