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
    "Theodore Y. Ts'o" wrote:
    > Date: Wed, 06 Oct 1999 11:37:31 -0400
    > From: Alex Nicolaou <anicolao@mud.cgl.uwaterloo.ca>
    >
    > "Theodore Y. Ts'o" wrote:
    > > I claim that there are better interfaces than readdir() +
    > > stat() and a dynamic filesystem in order to pass this information to
    > > userspace, though, and I hope most people would agree with me. Why
    > > don't we try to design that interface first, and I suspect the rest will
    > > follow relatively easily.
    >
    > Can you propose a better interface? I don't really understand your
    > comment, because the UNIX filesystem has always been the namespace
    > for operating system objects....
    [snip]
    > A much better interface for getting the information out to the daemon in
    > one fell swoop would be something like /proc/devices (except we would
    > want to list the minor and major mode devices). There would also need
    > to be an interface where a user-mode daemon could be informed of
    > changes; some kind of synthentic file which the daemon could select() or
    > poll(), and read() from to find new devices. Surely this is better than
    > forcing the daemon to periodically run readdir() over all of /devfs
    > looking for new devices!

    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.)

    I think I misunderstood your post to be suggesting that we not provide
    the device functionality via the filesystem, but rather use a different
    interface. However, now I misunderstand your post to mean that you just
    don't want to name it /dev and administer it with /devfs but would
    rather name it /proc/devices and administer it a different way, while
    living with the limitations of the existing interfaces. I think my
    confusion stems from the use of the word "interface" to describe the
    overall way of interacting with devices as opposed to meaning specific
    system calls...

    I personally don't care much about which solution to this particular
    problem is actually chosen. However, I think that the ability to know
    when an inode is modified makes the problem easier to solve no matter
    which solution is used for the devices issue, as well as solving other,
    "unrelated", problems.

    alex

    -
    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:0.024 / U:29.620 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site