On Mon, May 26, 2008 at 08:54:10PM -0700, Garrett D'Amore wrote: > > Background: > > * I need a way to store driver-specific tunables, whose values may > vary from one instance to another, and may be changed by an > administrator from time to time. > > * This is for audio drivers, and the tunables may cover things like > jack configuration (e.g. the orange jack is digital in, or its for a > subwoofer), or other things (like default volume levels). > > What I need, is not unlike what Brussels provides for NIC drivers. > driver.conf(4) is unsuitable for a number of reasons -- not least of > which is that it is unwieldy for administrators, particularly when > attempting to use it for configurations specific to a particular audio port. > > Brussels stores this configuration data in a file in /etc, administered > via dladm and uses a daemon and door upcall to synchronize kernel and > userland/filesystem accesses. > > It *seem* to me, that a potentially superior way to handle this, at > least for my needs, is to figure out who to use SMF service properties. > The challenge becomes getting access to such properties from the kernel, > and notification in the kernel when certain properties are added or changed. > > Has anyone given this wider thought? Any places in particular I should > look? Should I use something someone else is doing? Or should I look > into creation of a kernel/SMF synchronization service? Or should I just > go the same route that Brussels took, and invent my own data store and > backing daemon? > > Any thoughts are greatly appreciated. > > -- Garrett
There isn't a good mechanism for this right now. There should be one. We discussed this long ago at the time of original SMF design but the work to do it has yet to be initiated. There are really two important issues, one in terms of design philosophy and one implementation: - From design philosophy perspective, we don't want this to become a dumping ground for developer tunables. SMF is for expressions of administrative intent, not a namespace of unstable implementation details, along the lines of past messes like etc/system, driver.conf, ndd etc. - From implementation perspective so that things can be read early during boot one has to somehow segregate or cache driver-related settings in some form that can be read more easily from the kernel than the smf database. >From the perspective of current implementation, we in effect already have the necessary driver APIs to load properties from file or serialized nvpair pretty easily, and we have the mechanism underlying update_drv to trigger updates, so the way I would suggest approaching this is to develop a model for driver instances in smf(5) which permits one to publish a *subset* of properties that are suited to administrative intent, and have those property values be stored separately in serialized nvlist form. The first design step to take, though, is really to figure out the appropriate mapping of driver concepts on to the smf state machine, or to extend it appropriately, so that we end up with some mentally consistent model of what this means. -Mike -- Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/
