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
    [I've replied to a number of different people in one message, since I
    don't particularly like the fire-15-different-replies-for-each-message-
    found-on-thread style of debating which some poeple seem to have
    adopted. I've also not bothered responding to ad hominem attacks. -- Ted]


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

    If we posit that in the long-term, we *have* to have a user-space
    component to solve the dynamic /dev problem --- that trying to do things
    like keep track of USB topology in a file or database in kernel space is
    madness, etc. --- then readdir() + stat() is not the right interface.
    It's a very inefficient way to get necessary information to the
    user-mode daemon!

    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!

    Note that once the daemon has the information, it can do anything it
    wants with it. For example, if having a clean /dev directory is the
    holy grail for some people (it isn't for me, but different strokes for
    different folks), a user-mode solution can be configured to do this as
    well as provide for user/group/permissions persistence: the daemon would
    simply have to stat() the device, store the information in some kind of
    file or database, and then rm the device node. The point is that it's
    infinitely more to do things in user-mode than in kernel mode.
    Different people can write or modify the own user-mode daemon much more
    easily, depending on their religion about how they want to maintain
    /dev --- and if nothing else, this discussion has definitely shown that
    there are lots of different opinions about what's the Best Way to manage
    the /dev directory!


    Date: Fri, 8 Oct 1999 03:04:43 -0700 (PDT)
    From: Dan Hollis <goemon@sasami.anime.net>

    > UUID-based mounting comes to mind. And it already works.

    This only applies to filesystems with UUID. What about filesystems without
    them (eg iso9660)? What about tape drives?

    Tape drives use a completely different name space already (/dev/staX).

    As far as iso9660 filesystems, they do have volume labels, as do most
    filesystems, and you can always do mounts based on labels. With ext2
    you can do things both ways:

    LABEL=temp /tmp ext2 defaults 1 2
    UUID=3a30d6b4-08a5-11d3-91c3-e1fc5550af17 /usr ext2 defaults 1 2

    The advantage of doing things like this is that this makes mouting
    devices independent even of the SCSI ID! You can re-arrange the SCSI
    ID's, or if you're using JAZ cartridges, with a series of JAZ drives,
    put the removeable cartridges any one of the JAZ drives, and have the
    Right Thing Happen.

    Another example of my mounting by volume label (which Solaris's vold
    does, by the way), is if you have a jukebox of CD-ROM players. No
    matter into which drive you insert a particular CD-ROM, it will get
    mounted in the right place because vold consults and internal database,
    and given a specific label the CD-ROM will get mounted in the right
    place. (There's also a default where if the CD-ROM isn't yet in the
    database, it will get mounted into some location based on the volume
    label.)


    Date: Thu, 7 Oct 1999 19:43:45 -0500
    From: Grant Erickson <grant@lcse.umn.edu>

    Take for example, a switched Fibre Channel fabric configuration (such as
    the one here at the University of Minnesota which changes VERY often
    during develoment and test work). The Fibre Channel standard allows:

    239 switches per fabric, 255 ports per switch, 126 devices per port

    Even accounting for interswitch links, that's about 7.6 million disk
    drives (or other devices) that could, in theory, be connected to one host.

    Those drives can move from one switch port to another switch port or from
    one switch to another switch on the fly. Further, the topology of the
    fabric can change on the fly. A device naming and allocation system which
    accounts for this would be great. Neither Solaris nor Irix handle this
    right now, it'd be nice if Linux could handle it whatever the solution
    finally is.

    You're talking about a Storage Area Network (SAN) here, and it's not
    clear to me that a SAN is ever going to be best exposed as devices in
    /dev, no matter whether /dev is static or dynamic. A SAN is much more
    like a network, and just as putting all the hosts in the Internet into a
    directory that might be exporting NFS filesystems and expecting "ls" to
    work is probably not realistic, I don't think trying to put all of the
    disks attached to a SAN on a directory is all that realistic either.

    IMO, in the long term, SAN disks will want to be named by UUID, and the
    filesystem layer is going to have to manage which disks together make up
    a particular filesystem, and some kind of named-like name service daemon
    how to find a particular disk, since we *do* want to be able to handle
    moving the disks around (for example, when a disk is moved from Los
    Alamos to Sandia, assuming that the SAN fabric has long-distance
    encrypted links between Los Alamos and Sandia National Labs --- to use
    an example from last month's Scalable Global Parallel Filesystem
    Workshop in Santa Fe).

    - Ted



    -
    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.941 / U:0.504 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site