lkml.org 
[lkml]   [1998]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
    On Fri, 7 Aug 1998, H. Peter Anvin wrote:

    > > People keep proposing bandaid solutions that only treat the
    > > symptoms.
    >
    > Yes, unfortunately devfs is exactly that.

    No, devfs is the solution to the problem that Unixes dev is stupid.
    Treating the symptoms would be making more room for major and minor space
    to deal with more devices. Look at unix98 ptys for another symptom fixing
    bandaid.

    The actual hardware is dynamic. The device drivers are dynamic. Dev needs
    to be dynamic.

    Linux needs to be Unix compatible. That doesn't stop it from being better
    then Unix.

    Capibilities are not something that was orignally Unix, but we will use
    them. This is because they are the right thing to do. They are important
    to security. SUID root is stupid.

    > > Device files are a namespace used to access kernel drivers, not just
    > > an ordinary collection of files. There is a fundamental difference here.
    > > It is critical that /dev be perfectly synchronized with the kernel.
    >
    > Actually, /dev *IS* just an ordinary collection of files. Yes, it has
    > to match the kernel. So do libc, kmod, automount, and a gazillion
    > other things. Putting it in kernel space is a quick, dirty hack.

    Dev is not just normal files. Dev files fill a stupid purpose. They act as
    symlinks between the file system and the kernel. They are an unnessassary
    level of indirection, they damage performance, they add confusion.

    Hmm. I've got a box here running an earley libc5 and a monilithic 2.1
    kernel. Ifconfig doesn't work right on it. But the computer works and I
    didn't have to update anything in userspace, although I did have to add
    device files to support more VTs. Libc and such dont need to be synced
    with the kernel. Perhaps it's better if they are but it is not entirely
    nessassary.

    > > Preferably, /dev is also synchronized with the hardware.
    >
    > There is no need for this; it needs to be synchronized with the drivers.

    It *must* be in sync with the drivers. It's better when it's in sync with
    the hardware.

    > > How would an anti-devfs person support USB? Remember, the whole system
    > > is dynamic. You can add and remove devices on a live system. You can
    > > have several devices of the same type, there is no adjustable ID like
    > > SCSI has... It will put you through hell.
    >
    > Do it like PCMCIA, which already supports this kind hot-plugging quite
    > nicely thankyouverymuch. Hot-plugging is a heck of a lot more than
    > device nodes, which is exactly why so many of the pro-devfs arguments
    > are fundamental fallacies.
    >
    > -hpa

    PCMCIA never adds enough devices do be a concern. Furthermore, PCMCIA is
    mostly used for things that dont have device files (nics, flash ram
    cards). Furthermore, with PCMCIA there is no clean way to tell if
    something is attached.

    How is a device file being invisable so differnt from the kernel reporting
    an error when you try to open it? At least if it's not there then humans
    can see the device isn't connected. Currently do detect the presence of a
    device, an app must run a device specific check or try to open the device
    file. If you have half a million device files, the open check could take
    awhile.. :)

    It's seems like alot of anti-devfs people dont like it because it's not
    traditional unix. They should keep in mind we do alot of things that arn't
    traditional unix. Most of us *love* proc. But with a mindset like yours we
    would never have it. Linux is not UNIX. It's unix compatible, stays close
    to unix theory and design, but is better.

    -
    Gregory Maxwell



    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

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