[lkml]   [1999]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc ation) )
    Nathan Hand <> said:
    > On Thu, Oct 07, 1999 at 05:32:14PM -0400, Horst von Brand wrote:
    > > Reasons against devfs:
    > > - Permanent attributes are kludged on
    > > - Breaks filesystem semantics in several ways, makes it very hard to check
    > > ramifications
    > > - Impacts system administration, making device managing a lot less Unixy
    > > - Impacts _every_ single driver in the kernel, even if it isn't used
    > > - What can be done with devfs can be done without it. Granted, it is less
    > > convenient. But I add/remove devices from my machines perhaps once a
    > > month, so that doesn't cut it for me.

    > Be fair:
    > - it doesn't impact drivers unless the developer chooses to use devfs

    If the _user_ uses devfs, the _developer_ has to provide it. A halfway
    system is worse than each alternative on its own.

    > - it doesn't impact system adminstration unless you enable the feature

    But does when enabled. One more variable to consider on each support call.

    > - it doesn't break filesystem semantics anymore than /proc already does
    > - UNIX devices aren't the best: tradition for tradition's sake is crazy

    > Also just because you don't add/remove devices very often doesn't mean you
    > are the poster child for all Linux users. I don't have any need for initrd
    > but I wouldn't dare argue it should be removed for this reason alone.

    I've never said that everybody is like me. I'm careful to talk about my
    experience, and what I have seen. As far, nobody at all has stepped forward
    telling the grueling story of his machine with hundreds of devices that
    change minute by minute, so I'd have to assume that this doesn't exist, or
    in any case is so marginal that any impact at all on the kernel used by
    millions that don't have any use for the feature is out.

    > > Reasons for devfs:
    > >
    > > - Makes handling hot-plug easier, but marginally so
    > > - Unclutters /dev
    > Be fair:
    > - gives sensible names to devices (c1t3d0s2 instead of sde)

    Change MAKEDEV, be my guest.

    > - eliminates scsi ordering problems because of sensible names

    /dev/c1t3d0s2 becomes /dev/c2t3d0s2 when you move the controller, and
    adding a new disk gets you to /dev/c2t4d0s2. How does this solve the "sdc is
    now sdb" problem?

    Check mount(8), options -L, -U for a solution to this.

    > - completely eliminates major/minor number problems

    Can't do that, because it is deeply ingrained into the kernel's way of
    handling devices.

    > - moves naming complexity INTO USER SPACE (good for usb)

    MAKEDEV is user space.

    > - user space scripts ran on insertion (just like cardmgr/PCMCIA)

    Can be done (sort of) with modules and pre- post- scripts. Not nice.

    > - UNIX-like /dev without UNIX-like rw fs (good for embedding on romfs)

    ROMFS is designed to be _small_, not full-Unix. I'd guess adding device
    nodes to ROMFS won't make it much larger. Surely much less than devfs and
    its bloat in all devices by itself.

    > - provides a proper namespace (no need for recent rash of /proc/*/dev)

    If you can't provide a proper namespace in /dev, then doing it as a fake
    filesystem is out anyway.

    > Notice that all of these problems can be solved in other ways (for example
    > you can solve the sde -> c1t3d0s2 problems using a startup script, similar
    > to how Solaris populates /dev) but devfs solves ALL of the problems in one
    > fell swoop.

    That isn't exactly right. As said above, it does not solve all problems.
    Plus the naming problem is still there, it is just shifted from MAKEDEV
    (yuck!) to either another configuration file (same yuck!) or the driver
    itself (double yuck!), which will have to find out if it is controller 2 or
    3 this time just for the sake of naming its devices (triple yuck!). Also,
    if you rename your disks that way, they will still be /dev/sdX for
    everybody else. The naming issue is _not_ local to your machine only,
    unless you prefer to live in a vacuum. Also, if something solves several
    problems in one fell swoop _without_ adding strange klugdes and needing
    extra machinery, it's an elegant solution (the conception behind Unix is a
    fine example). If not, it's just exchanging one mess for another one. My
    fear here is that devfs exchanges an acknowledged mess, which we know and
    over time learned how to handle in a reasonable way; with a much larger
    mess, one with unknown quirks that will have to be worked around. All for
    no real gain.

    > > Also: It is extra code, has to be maintained and updated, and has to be
    > > accounted for in new driver developments. It _will_ add new bugs, even new
    > > classes of bugs. This doesn't come for free.

    > Well, perhaps all kernel developers should stop coding right now: you have
    > equally well argued against all new features and drivers.

    Yes, I did. But if the costs involved are smaller than the benefits, go for
    it. If not, leave it alone. In this case, as no pressing need has surfaced,
    and no clear benefits have been shown, leave it alone.
    Dr. Horst H. von Brand
    Departamento de Informatica Fono: +56 32 654431
    Universidad Tecnica Federico Santa Maria +56 32 654239
    Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513

    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:54    [W:0.028 / U:8.212 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site