[lkml]   [2004]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectFuture devfs plans (sorry for previous incomplete message)
    	[Sorry for the previous incomplete message on lkml.  It was
    the first time I've seen xterm segfault in a long time.]

    Please do not delete devfs, as it provides important
    functionality unavailable elsewhere, and I have some plans to improve
    its implementation further.

    Part 1: Advantages of devfs

    devfs allows for creation of devices when user level programs
    need them rather than based on "hot plug" or modprobe-related events,
    neither of which do not exist for many devices and do not necessarily
    indicate need for the driver. This allow distributions to include a
    support for many more devices, without wasting a lot of unswappable
    memory, which adds up when there are a lot of potential devices and,
    in some cases, can make Linux perform better on platforms with limited
    RAM. I can think of four classes of such devices:

    1. hardware that does not generate "hot plug" events, such as
    a conventional floppy disk drive. This way, distributions
    can have support for all of these devices turned on without
    bloating the kernel.

    2. software devices, such as /dev/loop. Again, this way
    distributions can include support for any such devices that
    may be developed without a substantial cost in unswappable RAM.

    3. hardware that is incidentally plugged in, but which might not
    be used in the current session from boot to shutdown. With the
    increasing popularity of USB and firewire, a user might have a
    "webcam", a still digital camera, a digital video converter, a
    flash reader, a printer, a scanner and an external disk that
    happen attached to the computer's USB network, with the user
    having no intention of using any of them during the current
    session from boot to shutdown. This way, the cost of leaving
    some things plugged in for convenience is reduced.

    4. user level disk partitioning, which I've used for years, shrinking
    the kernel a bit, and possibly enabling one to avoid spinning
    up disks that are not going to be used.

    In addition, devfs's use of names rather than number for
    device identification in the kernel has the potential in the future to
    help avoid issues of device ID number collisions, the "Linux assigned
    names and numbers authority", and so on. System administrators that
    do not like using devfs names directly can use the mechanisms provided
    by devfs user level software to map to device names that they do like.

    In any software, there is always a limit point to the
    "mechanism versus policy" slogan where the complexity costs of
    providing more generality are believe to outweigh the benefits for the
    near future, especially if further generality could be added later if
    the need were to arrise. For example, most ethernet devices are named
    "eth%d", although we could conceivably add a translation layer for
    that in the future. I believe that at some point in the distant
    future, as part of a rearrangement of the distinctions between block
    devices, char devices and device mappers, the method for connecting
    the string passed to devfs_register() and the file name that
    ultimately appears in /dev might change, but removing devfs in the
    meantime would do more to impede such an effort and also would be
    throwing the baby out with the bath water due to other advantages of
    devfs discussed above.

    Part 2: Future plans for devfs

    Some time ago, I posted patches to replace the stock devfs
    implementation with a much smaller one based on a specialized fork of
    ramfs, replacing the devfs daemon with a facility for having the
    kernel exec a helper program on devfs events. The kernel code was
    about a fourth the size of stock devfs, and the user level code was
    also reduced by a similar factor. I use slightly updated version of
    that system on several systems every day, under 2.6.7. I can post
    updated patches for this, but I also plan to implement some change

    I plan to split out the functionality for invoking a user
    level helper program on attempts to find or create a file, which
    should provide the following advantages:

    1. non-devfs configurations will be able to have demand loading
    of device drivers that devfs systems currently enjoy.

    2. The kernel memory footprint costs of CONFIG_DEVFS will be
    even smaller, although the size of CONFIG_DEVFS +
    CONFIG_lookup_helper will probably be slightly more than
    that of my current mini-devfs.

    3. It may provide a daemonless alternative to autofs for some
    simple but common uses.

    4. It will probably at least take us a step toward kicking dnotify
    out to a demand loaded module (hey, it's unswappable memory that
    every system currently uses, every byte counts).

    5. It will probably provide a more general mechanism for
    implementing dnotify-like systems that people periodically post
    to the linux-kernel mailing list.

    I have not yet written this vaporware, partly because I'm still
    pondering the question of whether the facility for exec'ing a user
    level program should be done as a few new lines in ramfs, a fork of
    ramfs, or an extentsion and restructuring of dnotify. It should not
    be many lines of code. It's just that I want to get it right.

    Doing this as a ramfs variant would seem to contain the
    changes and assure the non-users of this facility that there would be
    no cost to them. So why not do it as a ramfs variant? Alas, doing
    the user level helper facility as a ramfs variant would require adding
    a parameter to inode_operations.lookup() because we need to filter out
    the lookup event that occurs when an inode is being created.
    Otherwise, in certain cases, loading a module that registers multiple
    devices can cause a deadlock when the module's initial registration of
    the device causes the devfs helper to block on trying to load the same
    module again. Also, I wonder if there might be some use for layering
    this facility on top of other file systems, such as /proc or /sys or
    arbitrary storage file systems, but I haven't yet been able to come up
    with any example. So, I think that making some general interface that
    both dnotify and this facility could be clients of will probably be
    the best approach, but there are definitely pros and cons to this
    choice, and keeping that code small is something that I want to be
    careful about.

    I can post a new mini-devfs patch if there is interest,
    although it may be the weekend before I have time to do even that.

    In the meantime, please do not delete devfs. Thanks in

    __ ______________
    Adam J. Richter \ / | g g d r a s i l

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

     \ /
      Last update: 2005-03-22 14:04    [W:0.026 / U:49.252 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site