On Wed, Jun 24, 2020 at 10:32 AM Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote: I remember the change from stty/gtty which was peculiar to tty's in v6 to ioctl in v7 and thinking it was a nice clean generalization. Then I realized it had at least two big issues -- no concept of direction nor the size of the container being moved. So, then I see it start to get abused and I said -- oh my -- that was clearly not well thought out. Plan 9's solution of the CTL file with an ASCII interface, I thought was cleaner. IIRC TRIX had a controller interface too, but I've forgotten the details now. Here is the problem.... if you make everything a byte stream (which is a great fundamental way of building up a small cooperating program with a common interface), how do you handle the mechanisms to modify the stream in a manner than make sense (control if you will) in an out-of-band manner, but not end up with a fisherman's stew of different and special things (access methods, frameworks, *et al*) that are peculiar to that specific stream? The problem with stty/getty was is was specific to TTY's. It was a fine OOB scheme, but did not make sense for say changing parameters on other devices (tape as an example). The tape solution was different names, which worked there because you were not supposed to change things like density mid tape write. Other peripherals worked differently. ioctl became the only way out, as Noel points out. So ... this begs the question? Does the ctl file idea work better than ioctl? You still have to know what the ctl interface is for that device? It is ASCII which is nice and huge improvement over the binary command encoding crap. Clem