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

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

[Andries.Brouwer]

> 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?

% man 2 ioctl_list

gives a very outdated list. Collecting the present list is trivial
but time-consuming. If anyone does I would be happy if he also
sent me an updated ioctl_list.2

Andries

[PS I released man-pages-1.36 a few days ago]

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

[Alexander Viro]

On Sun, 20 May 2001 Andries.Brouwer@cwi.nl wrote:

> > 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?
> 
> % man 2 ioctl_list
> 
> gives a very outdated list. Collecting the present list is trivial
> but time-consuming. If anyone does I would be happy if he also
> sent me an updated ioctl_list.2

Andries, I wouldn't call it trivial. Consider the following:
                default:
                        if ((cmd & ~(_IOC_SIZEMASK << _IOC_SIZESHIFT)) == JSIOCGNAME(0)) {
                                int len;
                                if (!dev->name) return 0;
                                len = strlen(dev->name) + 1;
                                if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
                                if (copy_to_user((char *) arg, dev->name, len)) return -EFAULT;
                                return len;
                        }

Real-world example. From drivers/input/joydev.c::joydev_ioctl(). And it's far
from the worst ones - just one I'm currently looking at.

We have ~180 first-order ioctl() methods. Several (my guess would be 8--15)
subsystems of the second order and hell knows how many instances in each
of them. And I'm afraid that we have some third-order families. Each instance
of each family got some ioctls in it. I think that we have several thousands
of these beasts.  And that's several thousands of undocumented system calls
hidden in bowels of sys_ioctl(). Undocumented == for most of them we have
no information of argument types, which arguments are in-, out- or in-out,
which contain pointers to other userland structures, etc.

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

[John Fremlin]

	Alexander Viro <viro@math.psu.edu> writes:

[...]

> We have ~180 first-order ioctl() methods. Several (my guess would be

Hehe. I suppose you already know about the way strace (@sourceforge)
kind of automatically tries to figure out the args for the common
ones?

[...]

-- 

	http://ape.n3.net

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

[Andries.Brouwer]

> Andries, I wouldn't call it trivial.

I am a mathematician. Definition of trivial in this case:
"No intelligence required, just patience and careful work".

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

[Alexander Viro]

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.

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. Finding a way to represent them in fs is
the least of the problems.

And we really need to rethink them. Repackaged shit remains shit and the
whole point of exrecise is to get rid of it, not to shove it into a new
pile.

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

[Abramo Bagnara]

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!

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

[Alexander Viro]

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.