Re: [linux-usb] Re: USB device allocation
Johannes Erdfelt (jerdfelt@sventech.com)
Fri, 8 Oct 1999 16:46:20 -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, 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.
Yeah, the user sets policy, devfs follows that policy.
> > 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.
I don't understand what you mean. Why can't it help with naming?
> 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.
devfs has the userspace. devfsd would be responsible for seeing that a
new device got connected, obtaining information useful to naming it,
and then naming it.
I have the feeling that we are on different wavelengths here.
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/