Artem Kachitchkine wrote:
>
> 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.
The point is that I need persistent configuration data. I can use this
with driver.conf(4) today, but that is *terrible*. Sure, I can wrap a
GUI around driver.conf, but even that is nasty since the actual format
of driver.conf is *different* for different kinds of parent busses!
I can invent a new registry just for this purpose, or we could come up
with something that is more widely useful.
It isn't fair to say that the fact that I need this is "wrong". There
is software configuration data which must be made to reflect hardware
configuration, and which cannot be autodetected. There is also *policy*
data (tunables) for some things that you just can't automatically tune.
(Although you can provide reasonable default settings for those, and we
do that. But for certain kinds of extreme uses, manual tuning may be
required. E.g. applications with unusual latency requirements may
require a smaller buffer size than the default, or a higher interrupt
rate...)
-- Garrett
> -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
>
