Edward Pilatowicz wrote:
On Thu, Apr 23, 2009 at 08:01:42AM -0700, Garrett D'Amore wrote:
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.)


so i've been watching the conversation and i haven't chimed in since my
views pretty much align with garrett's.  if you want to see a simple
driver that uses id_alloc() and friends to manage it's minor number
space, check out lx_audio.c.  the usage is pretty strait forward.

Look now while you still can though... I'm intending to remove lx_audio shortly after Boomer Phase I integrates. (Because with Boomer, we don't need the linux emulation layer for audio anymore. :-)

so while i don't see the minor number management interfaces as usefull,
i do see the state handle as potentially usefull.  i actually created
such a handle in an old prototype i did for stacked drivers many years
ago.  in that case, use of the handle was controlled by a cb_ops device
flag.  there was a one-to-one mapping between the handle and a given
minor node, and every driver in the stack had it's own handle.  the data
handles were stored in the common snode, and as long as all data access
was done via the filesystem or the ldi (and not directly via driver.c
interfaces), we would have access to the common snode to easily get the
handles.  this would save the driver from having to do any kind of
lookups internally.


I'm coming around to the idea of the state handle ... but minor *number* management definitely belongs in the driver, not in the framework (though using some other arena type allocation "helper" such as id_alloc() might be useful).

   - Garrett
ed
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to