On Tue, May 27, 2008 at 11:12:10AM -0700, Garrett D'Amore wrote: > A semi-concrete example is that the driver needs to register "mixers" > with the mixer framework. It does this at attach time currently. What > gets registered can be different depending upon these tunables -- such > as whether or not a port is going to be used for SPDIF output.
So allow the attach but let the device be useless until these tunables are updated somewhat later in the boot process. Alternatively, as Mike Shapiro suggested, export the config data stored in SMF into an nvpair list either really early in boot or at shutdown time (if the driver must load before SMF could possibly run and must have these tunables) and suck it in using existing kernel APIs. > You also need to have values that are persistent -- i.e. the driver > could detach (e.g. due to idleness), and when it gets reloaded later > (perhaps because it was now being used) you want to use the same values > it had before. This means that you really need a pull rather than a > push mechanism. Like volume. This is more interesting. > I am confident that I could invent my own subsystem to make this work. > I'm just not confident that inventing yet another wheel is a good idea. If you're the first one then go ahead and invent that wheel, but make it general if you can. Nico --
