[lkml]   [1998]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
       Date: Thu, 6 Aug 1998 10:43:19 +1000
    From: Richard Gooch <Richard.Gooch@atnf.CSIRO.AU>

    I hope you don't feel I'm a fanatic. Yes, I strongly believe in the
    correctness of the idea. And I've not yet heard of practical solutions
    to all of the problems devfs fixes.

    No, but certain devfs "cheerleaders" have been responsible for at least
    20 or 30 messages to linux-kernel just in the last 18 hours. Most of
    the messages say the same thing over and over again, as they feel
    comprelled to reply to any argument that might say anything vaguely
    negative about devfs, even if they've already tried to make the
    identical point twenty times before. This is why I had originally given
    up trying to debate the issue on linux-kernel, and why think devfs is a
    lot like GGI in terms of the type of discussion it inspires.

    1) devfs doesn't have to be mounted onto /dev if you don't like. The
    essential thing is that devfs provides a unique, logical
    namespace. You can always mount devfs elsewhere and make symlinks
    to it if you don't like the names

    We already have a unique, logical namespace; it's called minor and major
    device numbers. I know you (and others) don't like them, but many of
    the arguments against them are strawman arguments --- such as assuming
    that you will create all possible device files in /dev, whether or not
    the devices exist, and then complaining about the speed problem. Or by
    dismissing the reality that the dcache really does make the speed lookup
    problem pretty much irrelevant. (Yet in the last 18 hours, I can't
    count how many times I've just hit 'd' to messages which made the same
    flawed arguments over and over again.)

    2) which hacks are these? You mean using tar to save and restore the
    permissions? Would you prefer a C programme (something I'm
    contemplating doing)

    Precisely. In Unix we have a very well developed abstraction for saving
    this kind of state: permissions, user/group ownership, modtimes, etc.
    It's called a filesystem. Tar is an unmitigated hack; using a C program
    helps hide the fact that what you're doing is a hack, but it's still a

    What about the problem of when we move to 16 bit majors and the major
    table is dropped and we go to searching a list when we open a device
    node? How do you suggest we solve that?

    Going to 32-bit device numbers can be easily done during Linux 2.3; the
    glibc interface already supports it. We know where to store the 32-bit
    device in the ext2 filesystem, and how to do so in a backwards
    compatible way; we have abstractions in place that should make it more
    or less painless to go to using 32-bit device numbers. It's a mere
    matter of programming, and it isn't a lot of programming at that.

    As far as searching a list when we open a major number, again this is a
    extremely flawed and weak argument. First of all, the vast majority of
    systems out there will only have less than 16 major devices. A typical
    system has less than 10 major devices. (cat /proc/devices and see!) So
    searching the list is simply not a problem. If searching the list were
    an issue, there are plenty of ways of solving this problem internal to
    the kernel, without needing to make any user-visible changes --- such
    using hash table.

    We use hash tables for searching the inode cache --- you're not going to
    tell me that inode caches are bad just because a stupid implementation
    would have to sequentially search the entire list, are you?!? :-) This
    is what I call a strawman argument, and many of the devfs cheerleeders
    have been using such strawmans to argue their case.

    - Ted

    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:43    [W:0.022 / U:2.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site