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

[Linus Torvalds]

On Sat, 19 May 2001, Pavel Machek wrote:
> 
> Well, if we did something like modify(int fd, char *how), you could do
> 
> modify(0, "nonblock,9600") 

What you're really proposing is to make ioctl's be ASCII strings.

Which is not necessarily a bad idea, and I think plan9 did something
similar (or rather, if I remember correctly, plan9 has control streams
that were ASCII. Or am I confused?).

> I thought about how to do networking without sockets, and it seems to
> me like this kind of modify syscall is needed, because network sockets
> connect to *two* different places (one local address and one
> remote). Sockets are really nasty :-(.

One of the horrors of ioctl's is indeed that they are not very
well-defined, and as such cannot be transported over a network without
knowing more about them. Structuring them some way would already be very
useful. the _IOC() macros do this partially, of course, but because it is
a voluntary thing it is not actually followed all that well in general,
and most ioctl names are just random numbers that don't tell the structure
of the arguments or return values.

And a "stream of bytes" is in a very real sense the simplest structure,
and is the unix way (and the plan9 way is to avoid binary streams, and use
ASCII text instead when possible, whihc probably also makes sense).

However, you can't really use a string. It would really have to be two
memory regions: incoming and outgoing, with an ASCII representation being
the _preferred_ method for stuff that isn't obviously structured or
performance-critical.

Let's not take this too far, though.

		Linus