Re: [linux-usb] Re: USB device allocation
Johannes Erdfelt (jerdfelt@sventech.com)
Fri, 8 Oct 1999 15:51:03 -0400
On Fri, Oct 08, 1999, danielt@digi.com <danielt@digi.com> wrote:
> On Fri, 8 Oct 1999, Johannes Erdfelt wrote:
>
> > On Fri, Oct 08, 1999, danielt@digi.com <danielt@digi.com> wrote:
> > > On Fri, 8 Oct 1999, Theodore Y. Ts'o wrote:
> > >
> > > >
> > > > With a /devfs approach, you will still need to readdir() through all of
> > > > /devfs, figure out what changed, and then stat the device to see what
> > > > has differed. This also limits the information you can read out to what
> > > > is the stat()-style interface can provide, and that may not be enough to
> > > > give you the USB topology information. I suppose you could use
> > > > directories to represent USB hubs, but now you will have to recursively
> > > > search a directory tree to find the new devices! See what I mean? It's
> > > > a bad way of communicating this kind of information to the user process.
> > > >
> > > > The advantage of /devfs is that for folks who don't care, they can
> > > > simply overmount /dev and be done with it. But in the long term, if you
> > > > accept the supposition that you *need* a user-mode daemon, /devfs is an
> > > > inefficient interface.
> > > >
> > > Um, with devfs you do not need a user space daemon, so that daemon does
> > > not need to keep track of all the changes to the /dev directory, which
> > > promptly renders the rest of the argument irrelevent.
> > >
> > > If the user plugs in a USB modem, the user knows they plugged in a modem,
> > > they run their getty/pppd/minicom on the new modem device.
> >
> > No, no, no. No one seems to understand the issues at stake here.
> >
> > I have 2 modems, I plug modem A in first, it becomes (hypothetical)
> > device /dev/modem1. I plug in modem B second, it becomes /dev/modem2.
> >
> > Now, I unplug both and plug modem B in first, it becomes modem1 now with
> > the current naming system.
> >
> > This is completely unacceptable.
> >
> > Does devfs solve this problem right now? No. Will it be easy to solve
> > this problem with devfs when an appropriate algorithm to name PnP
> > devices is created. Yes.
> >
> OK, I think I understand. This is a problem that is more difficult
> to solve from a userspace daemon than it is from within the USB
> driver itself. All a userspace component would be able to do
> here is assign the appropriate name to the device, and with
> devfs the USB driver can do that directly. The problem is strictly
> with USB device naming so devfs is merely one possible solution.
Yes, devfs is obviously not the only solution, but IMHO is probably the
best solution since it already exists, is well thought out and would
easy to modify to do the appropriate work to determine a name.
Placing this naming in the USB kernel driver is not a good idea since
it's complicated. USB devices have serial numbers, but only SOME devices
have serial numbers. Naming based on topology information is possible,
but is obviously not a perfect solution. Placing all of ths into the
kernel is not a good idea nor will be it accepted (Linus has already
stated this).
However, using devfs is just my opinion.
The need for a userspace daemon to name devices based off of the little
amount of information that is possible to garner needs to be created.
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/