Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumberRegistrants]

[Abramo Bagnara <abramo@alsa-project.org>]

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!