[lkml]   [2003]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: DevFS vs. udev
    Thank you for the cogent reply.  I think all your substantiated
    points are valid. I'll have to see what I can do about the rest,
    as you said.

    I'm glad others responded to what seems like an inaccurate post of
    mine. At least I, if not others, can persue it as was suggested
    by you and Greg KH <> for now.

    I am not volunteering at this time to work on DevFS.

    The main problem is documentation, as you pointed out. I went to
    "make menuconfig" in the new stable kernel, and ran into this problem
    head-on: help for that option says that it is either depracated
    or obsolete, and after using it without big problems for a long
    time, I wanted to know why. Everything I saw after that smelled
    bad, and I'm saying so, but that may not mean that it is. It was
    so bad I didn't even read the "paper" about why on one of the
    referenced web sites. Also, my old 3 year archive via USENET
    of linux-kernel no longer exists within my grasp (not any fault of
    mine), so I'm forced to use web archive access, and it's hard to
    navigate in those.

    To respond to Greg KH, my uses are not for a highly production
    oriented mission critical corporate system or anything, but they
    are timing critical. If it takes more CPU, RAM, and time to open
    /dev/null and all the other hundreds of devices in /dev that get
    opened every time some programs start, that is not only bloat, but
    more trouble. Moving kernel functions into user space has always
    been a pet peeve of mine: why do it, when it just means shuffling
    back and forth between system calls and user processes ... if that's
    what is actually happening ... unless that's not what's happening
    ... I'll have to research this myself at some other time.

    okay. So I don't know what I'm talking about within /dev internals
    in the kernel. It's just not well documented. I can read the
    documents, then know what I'm talking about there, but all I'm
    trying to do is install 2.6. Ok, so I could have taken the word
    of the help system. Meanwhile, I've had to spend at least half
    a day re-configuring a non-DevFS /dev for the first time in half
    a decade in preparation for this big depracation, and I am upset
    about it.

    Sure, I could continue to use DevFS, but if as you said, it's not
    going to be around long, then I could be in trouble for depending
    on it.

    I'm going to use disk /dev for now, until I have time to understand
    this better, which will probably be around halfway through next year.

    Already, I'm living the old pain I thought was left way behind of
    archiving and moving around /dev subdirectories, and having to
    consider the differences between systems, kernels, distributions,
    and versions of backup, something I thought I didn't have to worry
    about. If udev gets OK or DevFS doesn't break, I may go back to
    that someday.

    For now, if whatever I do doesn't slow the system down more
    than about .1 seconds per access of *all* the /dev/ devices
    necessary for a complete program transition (in a swapping
    Pentium III), then I should be OK. Perhaps that was
    unconsciously nagging me: userspace =? swap; swap every time
    /dev gets accessed? If indeed this is just an undocumented
    transition, then my confidence is higher that you've made
    sure this isn't a problem, and I just didn't read about it.
    In one of my uses, /dev doesn't get accessed very often,
    perhaps once every half hour (giving it plenty of chance to swap
    if it has that ability, which I don't want it to), but when it
    does, it expects sub-second turnaround on the entire lot.
    If udev doesn't actually get used during device opens and closes,
    then that will fix that problem. Too many unanswered questions.

    Sorry for the "emotional" fuss. (Perhaps my personal environment
    needs less of that pressure, too :? )
    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 13:59    [W:0.026 / U:2.960 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site