Jordan Brown wrote:
> Garrett D'Amore wrote:
>> 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.
>
> One of the hardest problems in driver configuration is identifying
> which instance of the driver one is trying to configure. That's the
> source of the differences based on parent bus, because how you
> identify the device (at least at a primitive level) is different for
> different busses.
Yes, I understand that.
>
> Probably better is to key the configuration off of the /dev name,
> which hides that lower-level stuff.
Well, I'd settle for driver name and instance number. This is probably,
in some respects, simpler than /dev names, which can vary for different
kinds of devices (and some drivers might not even have a node in /dev!)
>
> 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'm personally a deranged weirdo who likes the idea of putting every
> tunable in the universe into SMF, so that there's a single mechanism
> for managing them. There's a scaling problem - we'd need mechanisms
> to hide most of them most of the time - but that seems tractable. I'm
> also one of the only people in the world who *likes* the Windows
> Registry. I recognize that I'm alone on my planet.
I'm not sure you're alone (why else systems like GConf?) While at one
point I despised it, I have gradually come around in my thinking -- have
a single repository where system software can store name-value-pairs for
configuration data seems useful. What I don't like is having the same
repository used for application data, or per-user configuration data.
But that's a different debate.
-- Garrett
