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

Reply via email to