> 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.
You could also dynamically allocate major numbers if you had something like
devfs. only have hard disks, a keyboard, a mouse, a framebuffer, and 'misc'
devices, majors 0-4.
If of course, you felt like doing that :)
> 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.
right. The 'checking' policy currently isn't there =(
> 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.
Yes. Pretty much said that any sort of heuristic for this problem would be
fundamentally broken because there is no 'right' way of doing things, and
that he would not take any patches trying to figure out the best logic for
this - because that code would just grow and grow as cases came up that
people wanted to 'adapt it' for.
And since devices get dynamically swapped, the only 'true' way to be sure
you have the correct device on lookup is to never assume that the device
layout is going to be the same from second to second. I believe he was
seeking for something that could be considered constant for a given topology
(not usb topology as much as topology for all devices in the system, for all
busses, drivers, etc). So as long as nothing changed, things would be the
same. If something was for instance unplugged from USB, and a new device was
plugged in, the device order for everything else would stay the same, just
that one device would change (assuming USB topology was the basis of the
device ordering for the USB core driver)
So what this basically does when taken to the extreme, scarily enough, is
eliminate the major number. We get 65,536 devices, and rely on something
external to the devices to tell us which is which. Like a daemon creating
readable links.
> > 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?
We would have to support a bus interface to the device and an actual
'device' interface. USB Printers are just special parallel ports, there is
no difference until you start to do things like read device status or put
the printer to sleep.
> > 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.
I really see the trend of hardware going toward plug-and-play. So (if I am
right) this is not a USB issue, it is a trend of all future hardware. A
'solution that works' could last us for a while, but I agree that it will
pretty much be the same flamewar everytime this is brought up... so it would
be nice if it was not just a 'hack that will last us through to 2.5.x',
because while I am sure some of you who have read my messages have figured
out I have a strong sense of sarcasm, I really really do not enjoy this at
all.
-David Waite
-
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/