Garrett D'Amore wrote:
I think this proposal is well intentioned, but from my previous
experience in trying to "manage" minor number spaces in portable
frameworks, its hard to get this right.
From your previous experience, do you think that it is worth spending
time and effort trying to get it right? Or is what we have now "enough"?
With some developer effort it works, but it doesn't really feel like
that it was designed to be used that way?
Device drivers may have multiple "real" minor nodes, which have
different behaviors. You usually have to have at least a decode of
the instance number, and possibly a decode of the "behavior". (E.g.
in the audio framework, I have to know whether the node was opened to
use the OSS API or the Sun API, and is it a "control" node (audioctl)
or a regular /dev/audio data transfer node?)
You can't rely on instance numbering either... some drivers might want
to have a single "dev_info_t" with multiple logical devices. (E.g. a
multi-port ethernet card, or an audio device with multiple independent
output ports but only a single PCI device.. I've seen both instances
occurs, so this is not merely hypothetical. Even the SDcard code has
this -- multiple SDcard slots on a single PCI function is specified in
the SDHCI specification.)
So, the problem is carving up minor name space.
You can offer drivers a convenience function, but you have to give
them a way to constrain the space from which they allocate minor nodes
& minor node state.
So even the simple suggestion of using id_alloc and friends is lacking
and may even be not suitable for all occasions: if the minor number
space has to have holes, of varying sizes.
(And you might need different state structures for different kinds of
clone opens -- e.g. OSS has very different state than the legacy Sun
Audio.)
I think this is less of a problem - the only state that can be passed
into an entry point other than open is what was set during open and it
is up to the driver to decide what to use.
So now I expect a driver's ioctl routine would know where to get the
pointer for the context based on the dev_t, whereas with what I'm
suggesting, the driver needs to know how to use dev_t to convert the
void* into the right pointer type.
Your proposal is also lacking in the detail for "parent" state. How
is that parent state (set of minor data) managed? Is the state to
track minor usage tracked per major in a master table somewhere? When
is the initial empty state allocated, and when is it freed? Will this
be automatic as part of modload/unload?
I've punted on this part of the design until I get a feel for whether
it's something to seriously pursue or if it isn't going to fly. Whilst
those details are important, they depend more on the implementation
rather than the design and I think they're much less important than the
other issues you've raised.
In short, while such utility functions may be useful for some, or even
many drivers, it will be difficult to make them generally useful for
all cloneable device drivers.
So are you implying that while it might be well intentioned, it's not
worth spending the time to try and get this right in order to be
generally useful?
And more detail is needed.
>
At the end of the day, I'm not sure it will save all that much code in
each driver. Maybe 100 lines, but probably less.....
Sure and it will probably take more lines of code to implement than it
will save me, myself, in what I'd use it for but that's not the point of
this idea.... the point is to simply make it easy to do simple things
without changing the game for those that don't need or want to use it.
Darren
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
