Mailing List Archive: USB Device Allocation: Let's keep on track!

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
Both solutions have some common points. As I see it, they are:
1) Both require a user-space daemon to configure the device, as necessary.
This daemon would operate very similarly to PCMCIA
2) Both suffer from only having 1 major -- with multiple USB cards, this
may not be enough minors. It has been suggested that the kernel code
be extended to possibly use multiple majors with a compile-time option.
Thus, on those systems with 800 devices, the right kernel switches can
be thrown to support them all -- but the default kernel doesn't tie up
the extra major number.
3) Both need a place where USB ioctl's can be sent, separate from
device-specific ioctls. It has been proposed that USB specific ioctls
act on the /proc/bus/usb/ tree, and device specific act on /dev/
Okay... those are the two options so far. I think what people need to
focus on right now is either (a) arguing that one is better than the other
(not just attacking one), or (b) proposing their own solution.
Please try to avoid flaming. Please. I get enough mail allready without
having to watch all these people get into a dicksize war. Nothing we
propose will be a perfect solution, in all likelyhood. So let's just get
a solution so that the USB device driver authors can go on and focus on
supporting devices.
Matt Dharm
--
Matthew Dharm InterNIC: MDD94
Engineer Cell: (619) 890-6943
Home: mdharm@one-eyed-alien.net Home: (858) 689-1908
Beep: page-matt@one-eyed-alien.net Beep: (858) 621-8155
Okay, this isn't funny anymore! Let me down! I'll tell Bill on you!!
-- Microsoft Salesman
User Friendly, 4/1/1998
-
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/

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/