Being the pragmatic SOB that I am, I think it's time that we look at other
alternatives to USB devices allocation besides devfs[d] -- while I
disagree with Horst and those who oppose devfs[d], it would appear that
timewise it is not apropriate -- USB will be present in 2.4, and if
devfs[d] won't make it until 2.5, then we're going to have to do something
else. Yes, I don't like it. Yes, it means that if a devfs[d] is adopted,
it will be even more effort to test the old USB code. Right now, I don't
care.
What we need is a way to deal with allocation major/minor numbers to USB
devices in a sensible way, without devfs[d]. As I see it, there are 2
options on the table:
1) Allocate 1 (or more) major, and group the minors into pools based on
device type. i.e. 16 minors for printers, 16 minors for ACM, etc.
2) Allocate 1 (or more) major, and use all of the minors as a pool for all
devices
May I suggest another solution, which may be work out better? If you
assume the use of a user-space daemon (which both of the above solutions
require), have the kernel USB code allocate the major numbers
dynamically, and let the user-mode daemon get the major number(s) out of
/proc/devices as necessary. This avoids the problem you mentioned about
not liking the kernel to tie up extra major numbers just to accomodate
those rare systems with 800 USB devices.
If you like, the first major number can be statically allocated, and the
rest dynamically allocated if necessary, but in principle, all of the
major numbers could be dynamically allocated by the kernel. (Just pass
in zero for the major number into register_chrdev, and the kernel will
simply assign you the next available major number, automatically.)
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/