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. Probably better is to key the configuration off of the /dev name, which hides that lower-level stuff. 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? 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.
