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]
    Alexander Viro wrote:
    >
    > On Sun, 20 May 2001, Abramo Bagnara wrote:
    >
    > > I've just had a "so simple to risk to be stupid" idea.
    > >
    > > To have /proc/self/fd/N/ioctl would not have the potential to suppress
    > > ioctl needs for *all* current uses?
    >
    > No, it wouldn't. For one thing, it messes the only half-decent part of
    > procfs. For another, the real issue is how to eliminate the bogus
    > ioctls from userland programs and what to replace them with.

    Linus wrote:

    > The problem with ioctl is that not only are people passing ioctl's
    > pointers to structures, but:
    > - they're not telling how big the structure is
    > - the structure can have pointers to other places
    > - sometimes it modifies the structure passed in

    > None of which are "network-nice". Basically, ioctl() is historically used
    > as a "pass any crap into driver xxxx, and the driver - and ONLY the driver
    > - will know what to do with it".

    > And when _only_ a driver knows what the arguments mean, upper layers can't
    > encapsulate them. Upper layers cannot make a packet of the argument and
    > send it over the network to another machine. Upper layers cannot do
    > sanity-checking on things like "is this argument a valid pointer". Which
    > means, for example, that not only can you not send the ioctl arguments
    > anywhere, but ioctl's have also historically been a hot-bed of bugs.

    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 ;-)

    And it may works also via NFS (with some changes).

    > Crappy API won't become better if you simply change the calling conventions.
    > And problem with ioctls is that most of them are crappy APIs. Coming from
    > authors' laziness and/or debility.
    >
    > 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.

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

    --
    Abramo Bagnara mailto:abramo@alsa-project.org

    Opera Unica Phone: +39.546.656023
    Via Emilia Interna, 140
    48014 Castel Bolognese (RA) - Italy

    ALSA project http://www.alsa-project.org
    It sounds good!
    -
    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:3.191 / U:1.840 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site