lkml.org 
[lkml]   [1999]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-usb] Re: USB device allocation
    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/

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