> 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).
>
Using devfs you would register by name for clearly identified
devices, by serial number for unknown devices having serial
numbers and by topology for completely unknown devices.
The USB driver has to provide the names, devfs does not
set policy, it only provides a mechanism.
> However, using devfs is just my opinion.
>
devfs is not a solution for the naming problem. It is
a convenient mechanism if the naming problem is to be solved
from the driver.
If the naming problem is going to be solved from userspace, devfs
can help but it is not a "magic bullet" in that respect.
NOTE: while it cannot help with naming, it can ensure
that you at least have a device regardless of name.
So to borrow from myself:
Daemon: select on /dev/USB/status
Driver: Hey! I just registered /dev/USB/213987rywsl!
Daemon: What's that? I better ask my user what that is!
> 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.
>
The userspace daemon should probably not be responsible for primary
device creation in this case, if it gets confused we are still
falling back on arbitrary naming schema and may not get devices
without a manual mknod. At the very least with devfs we get
a topologicly named device that the user space daemon can ask
the user for directions on.
-- Daniel Taylor Senior Test Engineer Digi International danielt@digi.com Open systems win.
- 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/