lkml.org 
[lkml]   [1998]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectdevlinks: an alternative to devfs
    Here is another idea: devlinks, an alternative to devfs

    A devlink is similar to a symlink, but with the name of a device
    driver rather than the name of another file:

    /dev/cua1 *-> char/tty:1
    /dev/hda *-> block/ide:0

    A devlink has an owner, group, and permission bits, which can be
    set in the usual way. A devlink persists across crashes and shutdowns
    with no special work.

    The system administrator can rename a devlink to whatever they want,
    so FSSTAND remains a user-space convention and is not enforced by
    the kernel. Administrators can also create devlinks wherever they
    want, for example, inside a chroot'ed file system.

    Implementation-wise, a devlink can be implemented as a symlink with
    some magic bit set (obviously only the super-user can set that magic
    bit).

    When a driver initializes (either at resident boot time or at module
    initialization time), it needs to create devlinks in /dev. devfs
    has a similar requirement that /dev be mounted at some point.
    I propose a new system call, devctl( AUTO_DEVLINKS_GO_HERE, "/dev" ).
    'init' or an init-job would issue this system call early in the boot
    process.

    With devlinks, this doesn't have to be right away, because all of the
    existing contents of /dev are available as soon as the kernel boots.
    So /dev/null, /dev/console, and any other essential /dev entries should
    continue to be distributed as part of the root file system. It's only
    the auto-created devlinks that need to have /dev "marked" in order to
    auto-create. This solves a problem that devfs has, which is that
    devfs needs to be mounted very early in the boot process and probably
    can't be an ordinary /etc/mtab entry.

    I have another devctl call, devctl( SEND_ENOENT_TO_KERNELD, "/dev" ).
    After this is executed, any time an "open" call fails in the directory
    "/dev", it gets forwarded to kerneld so that kerneld can do module
    auto-loading (and then the module auto-creates its devlinks).

    devctl allows a lot of flexibility during development and keeps all the
    policy out of the kernel.

    devlinks could also specify parameters to their drivers. For instance,
    all of the /dev/fd* files would become devlinks like this:

    /dev/fd0 -> block/fd:0
    /dev/fd0D360 -> block/fd:0,format=360
    /dev/fd0D720 -> block/fd:0,format=360

    Devlinks coexist with the current system of block and character special
    files. Drivers can be upgraded one at a time to support devlinks.

    Devlinks can appear in any file system type that supports them.
    They require only a little bit more code than symlinks. A file system
    that doesn't support symlinks isn't suitable for /dev, but that's already
    the case right now.

    Devlinks can be put anywhere the administrator wants, such as chroot
    jails, or devlinks in /tmp during a system installation.

    Devlinks solve the limitation of 8-bit minor numbers almost forever
    (there is some huge limit on the length of a filename but I doubt that
    will ever be a problem).

    What do you think?

    Michael Chastain
    <mailto:mec@shout.net>
    "love without fear"

    \
     
     \ /
      Last update: 2005-03-22 13:41    [W:0.021 / U:1.152 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site