Jordan Brown wrote:
> Garrett D'Amore wrote:
>
>>> 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!)
>>
>
> In some ways, yes, but OTOH it's not as directly human-understandable.
> Not that any of the device identifiers are very good for humans. The
> best answers are based on some of the almost-never-implemented
> "connector" identifiers, which would in theory let the platform and the
> device say things like "the orange connector on the card with the 'B'
> printed underneath it"... but only the platform and the device can
> supply that kind of information, and they probably don't, so you've got
> a chicken-and-egg problem.
>
> Also, there is an excellent argument that the driver name is an
> implementation detail and that it is the /dev name that is the
> appropriate abstraction. Should the identifier for a particular
> physical device change just because you changed which chunk of software
> is driving it? (Yeah, I know it *does* change for many or most devices,
> but is that a bug or a feature?)
>
>
>>> 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 can believe that's true for some devices, but not many. Changing it
> might require a driver redesign so that the device is relatively inert
> until the config application runs, but such a redesign should be on the
> table. (I mean, if we're going to design something, maybe the right
> thing to design is the driver.)
>
> Can you offer a concrete example?
>
A semi-concrete example is that the driver needs to register "mixers"
with the mixer framework. It does this at attach time currently. What
gets registered can be different depending upon these tunables -- such
as whether or not a port is going to be used for SPDIF output.
Another example is that the tunables can impact preallocated resources
-- for example, we allocate some DMA regions based on the number of
fragments and fragment size which are potentially set to some "maximums"
at attach() time.
I don't disagree that some of these could be cleaned up a bit.
You also need to have values that are persistent -- i.e. the driver
could detach (e.g. due to idleness), and when it gets reloaded later
(perhaps because it was now being used) you want to use the same values
it had before. This means that you really need a pull rather than a
push mechanism.
I am confident that I could invent my own subsystem to make this work.
I'm just not confident that inventing yet another wheel is a good idea.
-- Garrett
