Re: [TUHS] VFS prior to 1984

[Clem Cole <clemc@ccc.com>]

[-- Attachment #1: Type: text/plain, Size: 2280 bytes --]

On Wed, Jun 24, 2020 at 10:32 AM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     > From: Dave Horsfall <dave@horsfall.org>
>
>     > 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...
>
> Like they say, when the only tool you have is a hammer...
>
> Better syntax than stty/gtty, maybe but I'm not sure the semantics are that
> much better. The problem is that, especially with devices, what the I/O
> commands do is so widely varied that it's hard to fit them all under a
> unified umbrella. Maybe some (e.g. asynchronous I/O), but not all.
>
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

[-- Attachment #2: Type: text/html, Size: 3539 bytes --]