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.
Darren
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code