On Thu, Apr 13, 2000, David Elliott <dfe@infinite-internet.net> wrote:
> Johannes Erdfelt wrote:
>
> > On Thu, Apr 13, 2000, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> > [SNIP]
> > I want mouse A to always be named mouse0, and mouse B to always be named
> > mouse1, EVEN if I connect mouse B in first. It should be named mouse1
> > and mouse0 should be empty.
>
> Why? mouse0 and mouse1 are kernel labels that are assigned based on which
> device was found first, same with eth0 and eth1.
When I use /dev/mouse0, I always want it to be the same mouse, not the
mouse which happened to be enumerated first by the USB bus.
I also want to know which mouse is which. As it is right now, the order
you plug things into the USB bus is they way they get named.
I can never know what physical mouse /dev/mouse0 is connected to.
> > > > Everyone seems to want to solve a specific problem but there's a larger
> > > > bigger problem everyone seems to be overlooking.
> > >
> > > And several small specific solved ones people keep missing too
> >
> > But they are irrelevant. They don't solve the overall problem. You can
> > keep naming these specific solutions, but they still don't solve the
> > problem for every device.
> >
> > Solving the problem on a per device basis doesn't make any sense for the
> > simple fact that it's specific to one device.
>
> Sure it does, unless there is some generically unique identifier that every
> piece of hardware has. I'll give you a hint: There isn't one! To determine
> one ethernet card from another, one may consider using the MAC address, or
> maybe the manufacturer+serial. For PCs with USB, MAC address would be fine,
> two cards with the same MAC is a broken concept on PCs. However, other
> architectures may need to rely on Manufacturer+SerialNumber to correctly
> identify one card from another.
>
> That is just ethernet. Then there are mice. I assume with a mouse you could
> use Manufacturer+Serial to determine which mouse it is. Probably same thing
> with a lot of other USB devices too (is this part of the USB standard??).
> Assuming there is some standard USB way of differentiating one device for
> another, then by all means use it, but don't expect the kernel to use it.
There is no guaranteed way of differentiating between devices on USB.
There are Vendor and Product strings, but 2 of the same mice look
identical. There is a serial number, but not all devices have serial
numbers.
With USB, as a last resort, you can use the bus topology. Devices are
generally plugged into the same place all of the time, but not always.
> Identifying one mouse from another, or one keyboard from another, or one
> graphics card from another, or one "foo" from another is a user space issue.
Applications shouldn't do this since it's an abstraction layer for a
reason, however, a daemon would be a good idea.
> Use something like Red Hat's "kudzu" to take care of this. If you would like,
> you can even make symlinks and stuff like that. For instance, have a
> /dev/aliases directory (making this up) which has symlinks such as:
> mouse0->/dev/usb/mouse0, mouse1->/dev/usb/mouse2, mouse2->/dev/usb/mouse1.
> Have a user daemon take care of identifying hardware and have it update the
> /dev/aliases directory with appropriate symlinks. If a device is not
> connected, then I would recommend its symlink be removed and then replaced
> when it is reconnected.
kudzu wouldn't be good enough because of the PnP nature of USB.
> This is just an example, I have no idea if those device names are correct,
> I am still running 2.2.15pre and I don't have any USB devices. I strongly
> believe that kernel device numbers should remain just that: kernel device
> numbers. However, to avoid having to come up with some sort of way to check
> which device is which, I recommend the symlink solution above (or some other
> standard user space thing) to handle all of that.
symlinks would be a solution. This is a good idea that something like
devfsd (or the other fictional program you mention below) could do.
I never said this had to be done in the kernel, just that there is no
solution right now and existing solutions were specific to the device
(or filesystem).
> > I think that devfsd can be part of the solution, but it's far from it
> > now.
>
> Yes, you could use devfsd to handle this, or you could create another daemon
> (probably a better idea, one program, one purpose) to handle the device
> mappings. Of course devfsd and the fictional program I mention are sort of
> similar I guess.
I don't see the reason to seperate them, but they could. Whatever,
that's not important.
I'm going to integrate something like this into my devfsd patches.
JE
-
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/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:23 EST