Darren Reed wrote:
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?
I'm not sure. Its a close call.
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.
Correct.
(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.
Yes. The problem is that there is not a good rule for mapping this
state... and without some knowledge of how minor numbers are used, it
becomes "difficult" to develop a general solution.
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.
OK.
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?
I'm saying that *may* be the case. It isn't clear to me.
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.
Of course the common code will use more. But you still have to do some
work to manage this state in the driver. I'm just not sure that the
effort you save will ultimately pay the dividends you hope to receive.
-- Garrett
Darren
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
