lkml.org 
[lkml]   [1999]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [linux-usb] Re: USB device allocation
    Date
    > -----Original Message-----
    > From: root@web4.dacotec.net [mailto:root@web4.dacotec.net]On
    > Behalf Of Martin Dalecki

    > Yes and there it is again. The admins say: "What a wonderfull hack!
    > there is a filesystem where I can echo 100000 > /proc/somemagic_file and
    > manipulate
    > this and that kernel behaviour. WONDERFULL! GIVE ME MORE I NEED devfs"
    >
    > But anybody more concearned with system design sees this and says:
    > "What a childisch idea. Files are data and file systems are for files
    > and
    > for nothing else. They shouldn't be abused as a backdoor to the kernel.
    > It's violating nearly every abstraction underlying
    > the overall system. It's twisted. It's ugly.
    > It's infecting the code all over the places.

    (I am going to get soo flamed for this)
    Oh yes, you are so right. Things like doing cat /dev/sndstat and getting
    audio statistics, or
    even something like cat soundfile >/dev/sound, such ugly ugly hacks. Files
    are data and nothing
    else. You should not be abstracting the underlying hardware with them. It is
    twisted, it is ugly.
    </sarcasm>
    How is this different at all? No really, how? If I can write pixels to my
    screen by writing to a file in
    dev, how is being able to adjust my LM hardware monitors by writing to a
    file in /proc different?

    Just in that the files in /dev are real system files taking up file space,
    and the files in /proc are dynamic,
    linked right into the kernel without the disadvantages of major/minor
    numbers.

    > system... And now they are eager to introduce
    > even more of this kind of stuff (Ahhh a tar cf blah /dev/* triggered
    > from kernel
    > level for persistency! WODERFULLL!). Ugh not too long in the future this
    > all will
    > be looking quite like the >Registry< just even worser becouse entierly
    > inside
    > the kernel. Ehh... And there is still the question how they will explain

    By the way, I don't think that the 'tar cf' is a bad solution, and I also
    don't think the registry is a bad solution (although in windows 95 it was
    definately badly implemented).

    I also don't think either should be kernel level, a registry daemon could be
    started in init, the same as
    parsing or creating that tar file.

    data is data, whether in a real filesystem with inodes or in a virtual
    filesystem.

    Anyways, the problem is that we are getting to the point where exotic
    hardware is _not_ an academic excersise. Someone could hook up 8 keyboards
    and 8 mice with a scanner and a printer for 8 lab stations today if it was
    supported. I should say _would_, the cost-conserned department would jump at
    the chance to get a single system to manage 8 stations, and perhaps only
    have ten computers requiring maintenance in the entire lab. But of course
    this is impossible today.

    We have an arbitrary limitation in place for absolutely no good reason,
    other than that it seems to some people to be easier to work around it
    forever than to actually think up a good solution and change it.

    I personally don't think devfs is the best solution, because it still uses
    the major/minor system. I think we need to figure out how to handle access
    to hardware that will not only not definately be there on reboot, but might
    not be there from one minute to the next.

    -David Waite


    -
    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.tux.org/lkml/

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