24 Jun
2020
24 Jun
'20
7:33 a.m.
On Jun 23, 2020, at 10:10 PM, Dave Horsfall <dave(a)horsfall.org> wrote:
On Tue, 23 Jun 2020, Warner Losh wrote:
(Slowly drifting off-topic (as all mailing lists do) so perhaps a new thread would be
better.)
Love it! On the other hand though, if an extra service is required of the OS and you
don't want to extend ioctl(), then that means Yet Another System Call (tm). I really
like the idea of /proc, so if there's an equivalent for ioctl() then I'd love to
see it; /sys would be an obvious choice, but it's already taken (Harris'
Lament).
No doubt, someone will now chime in and say that there's an existing mechanism
involving shared memory or something... My Unix-fu is getting rather long in the tooth
now (just like me).
plan9 has ctl devices that accept commands as ascii strings and mostly
return results as ascii strings too. Very handy. For example if you have
a optical disk drive you can send commands via its ctl device. There is
no technical reason why this model can't be adapted in Unix.
The fact is that the Unix byte/block read/write model goes only so far.
Every device has its own peculiarities that need to be queried or
controlled. And then there are controllers or USB device treees where
you can hang useful devices at varius places. Bottom line: while dealing
with real devices you can push this complexity around. You can't make it
disappear. At one point a friend and I were looking at building a
product using plan9 and one of the things I wanted to do was to make
sure that the "ctl" file for every device responded to a "help"
message
that yielded one line per command and "help <command>" for more details.
That way you can discover their capabilities at runtime.
Ioctl:
the Swiss Army knife of system calls. I thought it was a neat > idea when it arrived
(much better then those primitive stty/gtty > calls) but now...
More like the
swiss army chainsaw with engine trouble and a dull blade....