On Thu, Apr 13, 2000, David Elliott <dfe@infinite-internet.net> wrote:
> Johannes Erdfelt wrote:
>
> > 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.
I don't care what the names are. What I do want is a name which always
is the same mouse, period.
> > > 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.
I understand that, hence my clarification.
> > 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?
Yes, sorry. Hot Plug is the correct terminology.
> 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.
Having users run kudzu is probably not the best idea.
> 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.
I don't think so. Things like digital still cameras. They should just
work. There should be no reason a user has to have any intervention.
As for mice, they should also just work. In the default case, they
should all mix together. Of course, this can be configured to be turned
off.
However, I don't think it's possible for all devices, but it sure is for
many.
> > 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.
Ok, so we agree on that point then.
> 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 want it to just work when possible, no intervention.
I don't think this is going to be always possible, but like I mentioned
before, it is with many devices.
> > 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.
You need notification on insertion and removal and devfsd already knows
it.
devfsd is not a pretty program. It's pretty hacked together, but aside
from integrating new code into it, it already knows all of the
appropriate information.
> > I'm going to integrate something like this into my devfsd patches.
>
> Good idea.
Implementing is the best way to test it.
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