Darren Reed wrote:
Garrett D'Amore wrote:
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.
....
(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.
In reflecting on your comments, I think the best that I could offer
here would be to introduce a new flag that said the Solaris kernel was
going to manage minor device number allocation and that each open(9e)
call would get a unique minor number.
That would provide 2 scenarious: when the flag is set, kernel manages
all minor numbers and when it isn't set (like now), the driver is
responsible.
To try and have extra functions to allocate a minor number from a
given number space seems to start down a path of diminishing returns
when compared to the effort required to support it.
Very few devices would be able to support this.
The reason is that you have to separate the minor numbers *at least*
into non-cloneable and cloneable spaces... the driver needs to know what
the "original" minor number (not the cloned number) is so that it can
associated it with a specific instance.
For pseudo drivers where you have only one instance maybe this isn't
necessary (although it means your driver can never have more than one
"type" of minor node). For all other hardware drivers, you need to know
the instance number.
There's a reason that this hasn't been generalized before -- really. :-)
Being able to pass "state" with a minor number would be somewhat
useful. But having automatic minor number allocation is almost
completely useless unless you have some control over the pool of numbers
allocated from, and access to the "original" minor node that the device
opened (before the new clone number was created.)
-- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
