Messages in this thread | | | Date | Sat, 9 Oct 1999 19:50:18 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: USB Device Allocation: Let's keep on track! |
| |
Date: Fri, 8 Oct 1999 12:34:45 -0700 (PDT) From: Matthew Dharm <mdharm@one-eyed-alien.net>
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/
| |