Johannes Erdfelt wrote:
> 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.
>
What I am suggesting is that the actual name of the device should be assigned in order
as the kernel finds it. If you want nicer names that relate to the actual device you
are using, then you A) Need a way to identify the device (of course this is a given) and
B) a way to map the nice names to the kernel names.
Think of it as sort of being a relational database.
> [SNIP]
> > > 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.
>
Actually, I would personally prefer this, but most users would want an automatic
notification.
>
> > 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.
>
I see it as being the other way around, the user should have to verify the mapping they
want to use.
>
> 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.
>
Or even better, all non-configured mice/keyboards get added to the primary mix, that is,
the standard keyboard/mouse combo that is usually plugged into the PS/2 ports or
AT ports.
You then have the option of reconfiguring them to be a seperate entity and not mix in
with the primaries.
> However, I don't think it's possible for all devices, but it sure is for
> many.
>
The way I see it, when installing anything, the sysadmin should be asked about it, or at
least you should have that option. Putting the policy of "every device is automatically
configured" into even the devfsd is just asking for trouble.
>
> > > 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 want to see this. The very fact that we have different opinions on this should
encourage you to allow for either case. That is, don't put a bunch of autoconfigure
policies into the kernel and I would even stretch that to say, don't put a bunch of
autoconfigure policies into devfsd. Rather, autoconfigure only when it cannot be done
otherwise. By that I mean, autoconfigure a keyboard to "mix" to the primary stream.
The reason for that is your primary keyboard could possibly be USB. Everything else
should have to be specified in a config file. The people who want total
autoconfiguration can simply run a daemon to auto update the config file for devfsd.
The people who want full control can VI the thing and reload devfsd.
>
> > > 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.
>
Yeah... to sort of wrap it up here, I'd just like to say that I agree with you on a lot
of things, we do need something, but I really want to make it clear that doing the
autoconfiguration in devfsd itself is a bad idea. If you want fully auto configuration,
have another daemon to take care of that, update devfsds config and reload devfsd.
I know it sounds stupid, but then I plug in my shiny new "foo" USB device I can
configure it myself. When my mom plugs in shiny new "foo" USB device, it just works.
-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