lkml.org 
[lkml]   [2004]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectdevfs vs udev, thoughts from a devfs user
    I've been reading a lot lately about udev and how it's both very
    different to and much better than devfs, and with _most_ of the reasons
    given, I can't see how either is the case. I'd like to lay out why I
    think that is.

    I keep hearing about how udev has no naming policy in the kenel, while
    devfs has a fixed one and if you don't like it tough. But udev relies on
    sysfs, which IS naming policy in the kernel. And devfs has devfsd, which
    is a userspace daemon that listens to a kernel-exported filesystem (just
    like udev) and can create whatever /dev layout you want from that, in
    userspace (just like udev). Basically, udev relies on sysfs exporting
    device numbers. Well, imagine for a moment sysfs exported actual device
    files instead of just the numbers you'd need to make a device file (a
    pretty minor change, though not one I'm advocating). What you've got
    there is basically devfs and devfsd, right? Not the same
    implementation-wise, obviously, but essentially IDENTICAL concepts.
    Kernel exports device files to a kernel-generated filesystem, user-space
    daemon creates /dev from those with a layout according to your liking.

    Meanwhile, devfs (or a devfs-like solution) offer several things which
    udev just can't. Having a special kernel-exported filesystem just for
    /dev means your user-space daemon can see when a program is trying to
    access a device file that doesn't exist yet, you can't do that with
    udev and tmpfs. Moreover, it means you've got a functional /dev that
    accurately represents the system regardless of whether the user-space
    daemon is running yet. With udev, you're stuck with a static /dev unless
    udev is running. This can happen when broken system or doing a fresh
    installation, or if you accidentally break your udev binary. And heavens
    help you if linux ever moves to dynamic device files, that would make a
    static /dev completely unusable. Which would in turn mean that your
    system is unusable unless udev is running. It's not a big problem, but
    myself I find myself using devfs without devfsd for those two reasons
    every once in a while, and in those instances devfs is really nice.

    So the question is, is a devfs-like implementation really unfixable? And
    if not, is it worth whatever disadvantages can't be avoided? On the
    matter of memory usage, I'm really not sure why a new devfs couldn't be
    tied to the new device model. As I said earlier, it's only a subtle
    change from exporting a major and minor in sysfs to exporting a device
    file (in newdevfs or wherever). And I haven't heard anyone say devfs's
    race conditions are inherent to the idea, just that devfs's
    implementation has them.

    Finally, from /my/ experience, the one thing people disliked most about
    devfs was the long names for hard drive partitions. But isn't one of the
    first things on the agenda for 2.7 taking the partition detection code
    out of the kernel and replacing it with device-mapper? If you do that,
    then the block devices you actually USE are all device mapper created.
    They're already controlled by a user-space daemon. The real block
    devices are only used when you're partitioning (or LVMing, or EVMSing,
    or whatever). The rest of the time, in /etc/fstab or passing to mkfs or
    whatever else, you're using the dm devices. Now there's no reason
    a new devfs would HAVE to export long and unwieldy names for block
    devices, but if the only time you're actually using those names is for
    repartitioning, I really wouldn't care if they were long and unwieldy.
    It wouldn't show up in fstab, or df, or anywhere else the devfs style
    names have made a nuicance of themselves, so who cares?

    Sorry if any of these points has already been discussed on
    linux-kernel, I don't have time to read the list so I'm going based on
    what's been reported in things like kernel-traffic.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:00    [W:4.342 / U:0.764 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site