lkml.org 
[lkml]   [1999]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [linux-usb] Re: USB device allocation
On Tue, Oct 05, 1999, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> Date: Tue, 5 Oct 1999 18:19:30 -0400
> From: Johannes Erdfelt <jerdfelt@sventech.com>
>
> As it stands right now, there is no solution for naming of Plug and Play
> devices. I'm specifically interested in USB since that's what I work on,
> but this applies to everything plug and play (even PCMCIA)
>
> The problem is if you have 2 mice, how do you name? What if they are
> plugged in a different order, now 1 becomes 2 and 2 becomes 1.
>
> How do you differentiate between the 2? This can be difficult in USB
> since in some cases, 2 different mice look identical to the software.
> The only way you can differentiate is based on topology, exactly where
> it's plugged into the bus (which port on which hub).
>
> This is a problem that hasn't been solved yet.
>
> Exactly, and this is why trying to solve the problem in the kernel is
> the wrong way to go. There's enough state that you need to store, and
> policy that may be different on a per-site basis (user and group
> ownership and permissions), the USB topology information, just to name a
> few, that trying to do this in the kernel using a dynamic filesystem is
> madness.
>
> In userspace, a daemon can store in a database information about where
> the mouse is plugged into the USB topology, so that if the user
> designates that mouse #1 is the one plugged into the hub built into
> their monitor (for example), then on subsequent bootups the daemon can
> get this information from the database, and distinguish that mouse from
> the mouse that's plugged in somewhere else into the system.
>
> What other problems will be made easy to solve because of the power and
> flexibility of doing things in user space? The point is that we don't
> know, so we should use the more flexibility solution to solve our
> problem, instead of constraining ourselves with devfs.
>
> The big problem people haven't run into yet and haven't solved is the
> device naming issue.
>
> Naming is hard, no doubt about it. It's Computer Science's original
> rathole. This is why user-visible names (and names in /dev are user
> visible) should be done in userspace. We have much more flexibility,
> and it makes it much easier to Do The Right Thing.

I was advocating devfs because it's there. My understanding about devfs
now is that's mostly userspace. The only thing kernel space is a /proc
like dynamic fs interface for devfs. All of the policy is in userspace.

It makes very little difference to me if it's kernel or userspace
oriented. However, what I've read from all of the people that matter,
userspace is it and that's what it looks like it's going to be.

What needs to happen is some sort of acceptance behind devfs or
something else which is dynamic.

All I've seen about devfs and heard about it is, "Well, it's good, but I
don't know". This is probably one of the worst things that can be said
since it instills confusion over the future path of what's going to
happen.

Peter Anvin seems to be advocating some sort of completely userspace
daemon which uses a pipe or fifo (or something similar) to communicate
with the kernel when additions or deletions occur. The userspace daemon
then makes all of the appropriate standard system calls (mkdir, mknod,
etc) to create a somewhat traditional style /dev based on a users
policy. This seems like a good idea to me, but, I don't make these
decisions.

I think everyone has agreed that a daemon needs to exist, which is
userspace, has some sort of interface to the kernel to be notified about
additions and deletions and creates a /dev based on user policy. Do you
agree with this? Does anyone disagree with this?

Are the majority of people's problems with devfs based on the fact that
it has too much kernel code?

I don't want anyone to be offended with another email on this topic, but
there's a bunch of confusion over this (I'm probably the most confused)
and there has been no consensus on what to do.

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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.119 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site