USB Device Allocation: Let's keep on track!

Matthew Dharm (mdharm@one-eyed-alien.net)
Fri, 8 Oct 1999 12:34:45 -0700 (PDT)

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/