lkml.org 
[lkml]   [2001]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFD w/info-PATCH] device arguments from lookup, partion code

    On Mon, 21 May 2001, Ingo Molnar wrote:
    >
    > On Sun, 20 May 2001, Alexander Viro wrote:
    >
    > > Linus, as much as I'd like to agree with you, you are hopeless
    > > optimist. 90% of drivers contain code written by stupid gits.
    >
    > 90% of drivers contain code written by people who do driver development in
    > their spare time, with limited resources, most of the time serving as a
    > learning excercise. And they do this freely and for fun. Accusing them of
    > being 'stupid gits' is just micharacterising the situation.

    I would disagree with both of you.

    The problem is not whether people do it with limited resources or time, or
    whether they are stupid or not.

    The problem is that if you expect to get nice code, you have to have nice
    interfaces and infratructure. And ioctl's aren't it.

    The reason we _can_ write beautiful filesystems these days is that the VFS
    layer _supports_ it. In fact, the VFS layer has tons of infrastructure and
    structure that makes it _hard_ to write bad filesystem code (which is not
    to say that we don't have ugly code there - but much of it is due to
    historically not having had quite the same level of infrastructure).

    If we had nice infrastructure to make ioctl's more palatable, we could
    probably make do even with the current binary-number interfaces, simply
    because people would use the infrastructure without ever even _seeing_ how
    lacking the user-level accesses are.

    But that absolutely _requires_ that the driver writers should never see
    the silly "pass a random number and a random argument type" kind of
    interface with no structure or infrastructure in place.

    Because right now even _good_ programmers make a mess of the fact that
    they get passed a bad interface.

    Think of it this way: the user interface to opening a file is
    "open()" with pathnames and magic flags. But a filesystem never even
    _sees_ that interface, it sees a very nicely structured setup where all
    the argument parsing and locking has already been done for it, and the
    magic flags don't even exist any more as far as the low-level FS is
    concerned. Which is why filesystems _can_ be clean.

    In contrast, ioctl's are passed through directly, with no help to make
    them clean.

    Linus

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:53    [W:4.140 / U:1.320 seconds]
    ©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site