> 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
3) Allocate majors based on *functionality*, not interface type. (Clearly
if this had been done in the past we wouldn't have ten different
/dev/*mouse devices today...)
Example:
* video4linux already has its own major, so CPiA currently does (and in
the future should) use it.
* USB SCSI devices are treated like any other SCSI devices; they don't
have their own special pool of major/minor numbers for USB
sgN/sdN/scdN/stN--it would be no different from making separate pools of
/dev/aic7xxx_sgN and /dev/buslogic_sgN
Potential examples:
* Char major 6 is allocated to "Parallel Printer Devices". Is it possible
to hook up 256 parallel printers, using native parallel interfaces? Why
not devise a way of allocating minor numbers from that pool for USB
printers?
* The generic input driver framework at www.suse.cz already does this for
mice, etc.
>
> 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
The solution I just talked about, which has been discussed before on the
linux-usb list (sometime back in May, I think), doesn't have that problem
for the common case, which is "1 of each device". Obviously if you only
have one webcam/zipdisk/printer you don't have to worry.
It doesn't have that problem for the "more than 1 of each device" case as
long as you check to make sure you have the right device before you use
it.
You could write a daemon that makes symlinks for you, like symlinking
/dev/lp2 to /dev/laserjet and /dev/lp3 to
/dev/two_dollar_per_page_sublimation_printer or whatever, so you don't get
confused and print your rough draft to the dyesub printer. It can have
whatever policy you want to give it.
The only kernel support it needs is notification when devices are
added/removed, and some method for determining things like device IDs and
serial #'s if available, in order to give the user space daemon the
ability to make the correct links. It might also need a way to tell the
kernel to "activate" the device after the link is made, to avoid a race
condition (but if one chooses not to run the daemon, then the kernel
should automatically "activate" new devices).
I seem to remember Linus suggesting stateless allocation of minor numbers
based on topology, because otherwise if you plug and unplug devices you
end up with some mapping that depends on the order you plugged things in.
Then if you reboot, that mapping goes away.
> 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.
...which will not get used anyway, thanks to our static allocation of
major numbers. At least until other devices have compile-time options to
use different major numbers, this is not very useful. Plus I would
hate to have to add support for this to MAKEDEV :)
> 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/
Why? What does using a USB specific ioctl on a parallel printer char
device do besides return an error?
>
> 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
>
What's worse is it's more or less the same flamewar every time.
Brad
-
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/