Johannes Erdfelt wrote:
> 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.
>
My point is that you shouldn't. Assume we don't have a devfs at all and
/dev/mouse0 consistently maps to some MAJ/MIN combo. The kernel will therefore
assign mice as it finds them, which can even change from version to version of the
kernel as far as I am concerned.
>
> > > > > 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.
>
Okay, that's fine, do it from user space.
>
> > 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.
>
No, but user space!=application. By "user space" I just mean that you don't do it
in the kernel.
>
> > 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.
>
Err... kudzu is specifically for PnP.. Did you mean maybe because of the hot plug
nature of USB? Even then kudzu could take care of it.. Consider:
1. Plug in USB peripheral
2. Run kudzu and it gets recognized and the appropriate configuration is decided.
Or if you want a Win9x style system then:
1. Have some pseudo-daemon that runs when someone is logged a console (including
X), if something gets hotplugged in then it automatically notifies you and could
even simply ask for root PW (if you weren't logged in as root) and then run kudzu.
2. Plug in USB peripheral
3. Kudzu is run by the deamon.
So really it's no big deal. Now, if you want some sort of interface that has
absolutely NO sysadmin participation then I think you are crazy. If you are
plugging in a USB peripheral then it should be assumed you have access to login and
change the config.
>
> > 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).
>
What I am saying is that this should absolutely not be done in the kernel, it
should be handled in user space, most likely by a daemon. It may be possible to
use devfsd to do this. However, consider that for some situations (for example, if
the system has never seen the hardware before at all) you don't want to configure a
symlink for it, but you want to wait until the sysadmin intervenes and sets up the
mapping of his/her choice.
>
> > > 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.
>
It doesn't need to be.. I was just saying that I don't know if devfsd is up to the
task or not.. If it is then by all means use it. However, remember that you will
need some sort of configuration file that maps the unique identity of the device to
it's appropriate device filename. Any new devices should not be mapped until the
sysadmin has modified the config file, either with a kudzu-type thing or even by
hand.
>
> I'm going to integrate something like this into my devfsd patches.
>
Good idea.
-Dave
-
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