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 Sun, 20 May 2001, David Woodhouse wrote:
    >
    > If that had been done right the first time, you wouldn't have had to either.
    > For that matter, it's often the case that if the ioctl had been done right
    > the first time, nobody would have had to fix it up for any architecture.

    The problem with ioctl's is, let me repeat, not technology.

    It's people.

    ioctl's are a way to do ugly things. That's what they have ALWAYS been.
    And because of that, people don't care about following the rules - if
    ioctl's followed the rules, they wouldn't _be_ ioctls in the first place,
    but instead have a good interface (say, read()/write()).

    Basically, ioctl's will _never_ be done right, because of the way people
    think about them. They are a back door. They are by design typeless and
    without rules. They are, in fact, the Microsoft of UNIX.

    The only way to fix ioctl's is to force people to think about them in
    another way. Because if you don't, there is always going to be another
    driver writer who adds his own ioctl because it's the easy way to do
    whatever he wants without giving it a second of _design_ thought.

    Now, a good way to force the issue may be to just remove the "ioctl"
    function pointer from the file operations structure altogether. We don't
    have to force peopel to use "read/write" - we can just make it clear that
    ioctl's _have_ to be wrapped, and that the only ioctl's that are
    acceptable are the ones that are well-designed enough to be wrappable. So
    we'd have a "linux/fs/ioctl.c" that would do all the wrapping, and would
    also be able to do all the stuff that is currently done by pretty much
    every single architecture out there (ie emulation of ioctl's for different
    native modes).

    It would probably not be that horrible. Many ioctl's are probably not all
    that much used by any real programs any more. The most common ones by far
    are the tty ones - and the truly generic ones like "FIONREAD" that it
    actually would make sense to generalize more.

    Catching stuff like EJECT at a higher layer and turning THOSE kinds of
    things into real block device operations would clean up drivers and make
    them more uniform.

    Would fs/ioctl.c be an ugly mess of some special cases? Yes. But would
    that make the ugliness explicit and possibly easier to try to manage and
    fix? Very probably. And it would mean that driver writers could not just
    say "fuck design, I'm going to do this my own really ugly way".

    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:0.028 / U:30.620 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site