[lkml]   [1999]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: UUIDs (and devfs and major/minor numbers)
       Date: Tue, 15 Jun 1999 15:25:49 +1000
    From: Richard Gooch <>

    > This argument invites scrapping all of procfs.

    Yes. This is one of the most annoying things in this debate, and seems
    very hypocritical. If people want to use the purist argument against
    devfs, then they should be consistent. Get rid of procfs (at least,
    all the non-process stuff), autofs and knfsd.

    The purist argument is not that synthetic filesystems are automatically
    bad. For example, the rationale behind knfsd is one of performance as
    well as some correctness issues. Whether a sysctl vs. the non-process
    procfs approach is a better one is actually an interesting discussion,
    and that fact that we have both is a botch, but it doesn't necessarily
    mean we should eliminate all of /proc. Certainly the process related
    stuff can't be done any other way.

    Look to devfs as a way of cleaning up procfs instead. Move all the
    non-process stuff into devfs. That way we can get back to a procfs the
    way it was intended.

    Well, no, that doesn't work, since there plenty of non-process stuff
    which doesn't fit into a devfs mounted in /dev. Now, if you were to
    make an argument for a /kern that had the non-related process stuff, and
    perhaps one of the things in /kern was something like was is in
    Solaris's /devices directory, that might be interesting. What Solaris
    has in /devices are names which are designed to be unique and
    explicit about what they are attached to. For example, we might have a
    device name vaguely like:


    ...and then having a user-mode daemon make symlinks from /dev/sda1, or
    /dev/disks/<fslabel>, or /dev/scsi/disks/*, or whatever new experimental
    naming scheme that people want to experiment with. That's definitely
    policy that shouldn't be enforced by the kernel, so we would have a
    user-mode daemon that can consult a database (ala lspci, etc.) which can
    be changed when people want to experiment with different structures and
    hierarchies in /dev. This may or may not be the best approach, but I
    believe it's better than the current devfs approach.

    The bottom line for me is that kernel already has a very well developed
    backing store of files in /dev, and that's an ext2 or a minix
    filesystem. If you use that, then you don't need the tar file kludge at
    shutdown to preserve permissions. It's also clear that the decision of
    what the names of files in /dev really should be done in user-space, and
    should possibly consult a configuration file. There is clearly some
    functionality in devfs which is useful; but something which overmounts
    /dev really is the wrong long-term approach IMO. Maybe a
    /kernel/devices approach, combined with a reorg of the non-process parts
    of /proc is the right approach, but I don't have a strong opinion about
    that. In the end, even if we agree that /proc should be cleaned up,
    that doesn't mean we should put other code which makes similar design
    choices/mistakes into the kernel. It isn't hypocritical to say that
    both approaches are bad, and while we do need to fix /proc at some
    point, that isn't an excuse for devfs.

    - Ted

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.024 / U:1.444 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site