On Thu, Apr 13, 2000, David Elliott <dfe@infinite-internet.net> wrote:
>
> 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.
Umm, yeah.
The point I was trying to make is that ultimate goal is to have a name
which always points to the same device.
> > Having users run kudzu is probably not the best idea.
>
> Actually, I would personally prefer this, but most users would want an automatic
> notification.
> > 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.
Whatever, that's not important right now. Some people want it like this,
some want it like that. It's a policy issue.
> > 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.
That's what I was trying to say, but once again it's not that important
right now since it's policy.
> > 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.
You're making the assumption that there is a sysadmin.
But it's a moot argument anyway, policy.
> 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 was never saying that any particular policy should be enforced of any
other, but that certain different configurations should be possible.
We do seem to agree on that.
> > 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.
I don't think this is the exact way it should work, but I think we're
aiming for the same thing.
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