Brussels and Mario aside, I think that driver tunables is a concept that should be gently pushed into a dark niche along with assembly language and hand-written makefiles. I don't feel like it's worth the effort of careful architecting and interface stability. It should not be something that users face on a daily basis: if it is, you're doing something wrong. Whatever you invent, a system registry or a conf file, it's good enough.
However, if you introduce higher level abstractions (than driver instances), such as jacks or sockets or audio interfaces, then you can, and should, wrap it up into friendly CLI and/or GUI. Translation between these higher level abstractions and OS-specific device information should remain hidden from the user. -Artem 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 > > _______________________________________________ > brussels-dev mailing list > brussels-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/brussels-dev
