Re: [linux-usb] Re: USB device allocation
Johannes Erdfelt (jerdfelt@sventech.com)
Fri, 8 Oct 1999 15:29:34 -0400
On Fri, Oct 08, 1999, danielt@digi.com <danielt@digi.com> wrote:
> On Fri, 8 Oct 1999, Theodore Y. Ts'o wrote:
>
> > Date: Thu, 07 Oct 1999 17:11:32 -0400
> > From: Alex Nicolaou <anicolao@mud.cgl.uwaterloo.ca>
> >
> > My original post was meant to suggest that your proposed notification
> > method is not the right interface. There's a generic problem with the
> > UNIX fs design that there is no way to be notified when an inode
> > changes, and I think this problem could/should be fixed in a way that
> > allows any process to be notified of a change in an inode specified by
> > the application. Then you could wait for changes in /devfs or wait for
> > changes in /proc/devices and act on them. (Meanwhile GUI file managers
> > could efficiently display up-to-date directories without requiring a
> > manual refresh or wasting cycles calling readdir() repeatedly.)
> >
> > There actually has been some talk about extending the semantics of
> > opendir() and select() so that it would be possible to select() on a
> > file descriptor returned by opendir(), so that processes could be woken
> > up when a directory has changed. (And of course, if they aren't in a
> > select/poll loop, they can always fstat() the directory and look at its
> > modtime to determine if a directory has changed.) So yes, I accept your
> > point about wanting to know if an inode (particularly a directory) has
> > changed, and there are some clean ways we can extend the traditional
> > Unix API to give us this kind of functionality (particularly with the
> > poll() interface).
> >
> > However, even if you use this type of approach for /devfs, it's still a
> > cumbersome interface. Consider that with a /proc/devices-style
> > approach, a one or two read()'s will allow you to get all of the
> > information you need.
> >
> > 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.
> I personally think devfsd is a major mistake. Those who do not
> use it assume that its features are limited to a set that can
> apparently be addressed with an rc script. They also assume that
> it is necessary to use devfs.
Please solve the above problem with an rc script. I have yet to see one
created and if you could do so, you would greatly advance adoption of
PnP in Linux.
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/