>> Oh, and lots of new ioctl() to handle the "other stuff".

>No, as someone else already said, just open the ctl file and read/write
>it.  The only excuse for ioctl is code that needs to do things when
>handed just a file descriptor, like stdio doing a TCGETA on stdout.
>I'm not sure how to address that.

Simple.  Open /dev/fd/n/ctl, where n is the file descriptor.

That's the entire *point* of /dev/fd.

It is unclear whether there is any reason for most system calls.  Plan 9
is more unix than unix is these days.

ioctl was good for *speed* reasons; it's faster than opening, formatting
a request, and then interpreting the request, and then closing, a virtual
file (such as a /dev/fd file).  (Not sure if the terminology is right.)
The problem with it is the obvious one - it's opaque.  In a plan-9 style
solution, you accept the speed hit on ctl writes (come on, how often *do*
you change baud rate?) and get the speed and design win of being able to
sanely debug problems with them, and the lower number of system calls.

Come on, which is more likely to be wrong, an ioctl() where you specify
two flags, possibly adding instead of or'ing, or a write() of a readable
string.  More importantly, can you say off the top of your head which flags
actually share bits, and thus act up when added rather than or'd, or
remember when you see a number which flags it means?  A ctl device for a
stream is good for debugging and elegance.

-s