lkml.org 
[lkml]   [2001]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumberRegistrants]


    On Sun, 20 May 2001, Abramo Bagnara wrote:

    > Suppose now to have a convention that control stream are in the form:
    > "ACTION ARGUMENTS"
    >
    > Then we have
    > echo "speed 19200" > /proc/self/fd/0/ioctl
    > instead of
    > stty 19200
    >
    > It seems to me something different from a pile of shit ;-)

    But it isn't.

    a) You are still trying to think of it as an OOB data associated with
    normal channel. That is _wrong_. There is no 1-to-1 relation between these
    OOB channels and normal ones. Wrong model. Commands are not associated with
    data streams. Sometimes you can tie them together, but in many cases you just
    can't. Building the infrastructure on that is a Bad Thing(tm).

    b) Way too many ioctls do not have that form. So aside of converting
    code to handling the form above you will need to change the bleedin' APIs.
    Sorry. No way around that.

    c) Aside of implementing something dumb a-la XDR and putting encoding
    part into libc and decoding one into the procfs (which doesn't fix any of
    the problems and only adds to ugliness) any method means that you will need
    to go through drivers one-by-one. There is no magic way to deal with that
    mess at once - the whole problem is that this pile of dung was festering
    for too long and became a complete mess. The fact that anyone who felt an
    urge to toss into it did so without a second thought also doesn't help.

    I went through that crap about a week ago when I was doing audit of
    copy_from_user() callers. And I ask everyone who seriously wants to discuss
    the situation: go and read through that code. Write the APIs down. Stare at
    them. When you will get the feeling of the things out there (_not_ a vague
    "well, they are for passing some commands; how bad can it be?") join the
    show.

    > > So there is no easy way to solve that stuff - we'll need to rethink tons
    > > of badly designed interfaces.
    >
    > This is orthogonal wrt ioctl problems pointed by Linus.

    No, it isn't. That's the same problem. We have tons of garbage that will have
    to be converted to sane form _before_ we can do anything with it. Result of
    the braindead attitude of those who were dumping into that pile.

    It should be fixed, but it won't be easy and it won't be fast. If you want
    to help - wonderful. But keep in mind that it will take months of wading
    through the ugliest code we have in the tree. If you've got a weak stomach -
    stay out. I've been there and it's not a nice place.

    Getting a list of all ioctls in the tree, along with types of their arguments
    would be a great start. Anyone willing to help with that?

    > I've simply proposed an *infrastructure* for better interfaces.

    We already have that infrastructure. It's called ramfs. Building
    infrastructure on the model that doesn't fit the problem domain is a Bad
    Thing(tm). We already have enough ESRitis around.

    -
    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.067 / U:0.200 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site