[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)
    Theodore Y. Ts'o writes:
    > 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.

    Such as?

    > 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:
    > /kernel/devices/pci/adaptec2980_0/id0/lun0/part1
    > ...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.

    Explain to me how this is different from mounting devfs onto /kernel
    and using devfsd to populate a disc-based /dev.

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

    I've addressed this point in the past. There are two solutions I'm
    considering for this:
    - make devfsd to the saving/restoring
    - have devfs poke through to the underlying FS.

    But this is a straw-man argument, because it ignores the persistence
    problem with a dynamic disc-based /dev which is managed with a user
    space daemon. This is a problem that's been overlooked.

    Consider what happens if your daemon creates and deletes device
    entries based on information from the kernel as to what devices are
    installed (and drivers loaded). When a new device is plugged in, *what
    permissions should be given*? OK, say you get some default. So the
    sysadmin does chmod(1) to change this.

    What happens if a device is removed? The daemon deletes the device
    entry. Then the device is plugged back in again. *What permissions
    will be given*?

    So, your argument against devfs is really an argument against a
    dynamic /dev. But you don't really want to argue against a dynamic
    /dev, do you? You just want to argue about devfs.

    > It's also clear that the decision of what the names of files in /dev
    > really should be done in user-space,

    No, that's your opinion.

    > and should possibly consult a configuration file.

    So mount devfs onto /devices and configure devfsd to
    populate/depopulate /dev.

    > There is clearly some functionality in devfs which is useful; but
    > something which overmounts /dev really is the wrong long-term
    > approach IMO.

    The sysadmin gets to chose where devfs is mounted. It doesn't *have*
    to overmount /dev.

    Again I'll ask the question I've already asked a number of times. How
    would you cleanly support a construct like this:
    opendir ("/dev/ide/cd");

    and be assured that your loop sees only the IDE CD-ROMs plugged into
    your system, and also ensures the the right driver is loaded?
    This requires a virtual /dev, not just a dynamic /dev.

    Sure, you can get around it by having /dev/ide/cd a symlink to
    /devices/ide/cd, but then you're going to have to populate /dev with a
    pile of symlinks for hardware or drivers you might not even have.

    However, if you want to set up your system with a symlink farm for
    devices that you don't have, that's your choice. Mount devfs onto
    /devices and configure devfsd appropriately.

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

    Except that devfs isn't a mistake. It's the Right Thing[tm].



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