24 Jun
2020
24 Jun
'20
12:17 a.m.
Rob Pike:
For my taste, the various Unix file system switches that I've seen are too
firmly tied to the idea of blocks and disks and all that, making them less
flexible than they should have been. That's why the Plan 9 version is about
names and byte streams, to make it as general as possible.
=====
The only file-system switch I know well is that in the later
Research systems. It has nothing to do with disks or blocks.
It is about names and inodes: turn name to struct inode, read
arbitrary chunk of data, write arbitrary chunk of data, create
file, unlink file, abominable ill-defined system call that just
wouldn't die erm I mean ioctl, and so on.
It was certainly a cheap hack (as its author cheerfully admitted)
but it really was about I/O operations, not about simulating
disks. That's why it so easily supported /proc (the one that
was just about processes, not the misnamed Linux one that
is really about all things in the kernel so you don't need
/dev/kmem).
I don't know a lot about later VFSes like those in SunOS or
Linux or the BSDs. Blockiness might well have crept in in
support of memory-mapped I/O or in collaboration with the
buffer-cache implementation. The Research version was never
used directly to support different on-disk file system formats
(we did a different pjw cheap hack for the one case that
mattered in the kernel, and used the idea later developed
more by FUSE for other cases because speed didn't matter).
Norman Wilson
Toronto ON
24 Jun
24 Jun
12:24 a.m.
New subject: VFS prior to 1984
On Tue, 23 Jun 2020, Norman Wilson wrote:
The only file-system switch I know well is that in the
later Research
systems. It has nothing to do with disks or blocks. It is about names
and inodes: turn name to struct inode, read arbitrary chunk of data,
write arbitrary chunk of data, create file, unlink file, abominable
ill-defined system call that just wouldn't die erm I mean ioctl, and so
on.
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...
-- Dave
6:09 a.m.
New subject: VFS prior to 1984
On Tue, Jun 23, 2020, 4:25 PM Dave Horsfall <dave(a)horsfall.org> wrote:
On Tue, 23 Jun 2020, Norman Wilson wrote:
More like the swiss army chainsaw with engine trouble and a dull blade....
Warner
-- Dave
The only file-system switch I know well is that
in the later Research
systems. It has nothing to do with disks or blocks. It is about names
and inodes: turn name to struct inode, read arbitrary chunk of data,
write arbitrary chunk of data, create file, unlink file, abominable
ill-defined system call that just wouldn't die erm I mean ioctl, and so
on.
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...
7:10 a.m.
New subject: VFS prior to 1984
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).
-- Dave
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.... 
7:33 a.m.
New subject: VFS prior to 1984
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.... 
11:10 a.m.
New subject: VFS prior to 1984
On 6/23/20, Bakul Shah <bakul(a)iitbombay.org> wrote:
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.
Yes, complexity is unavoidable. IMO, the reason for going with a
purely file-oriented architecture isn't to make all user-visible APIs
use normal file calls, even though they are all going to be
implemented in terms of files (there's definitely a place for
libraries that provide a friendlier API on top of the file-based
transport). "Everything is a file" should not mean "all APIs are
visibly file-based".
The real advantages of a pure file-oriented architecture I can think
of off the top of my head are basically:
All security for all services in the system is enforced through a
single mechanism (rather than having many security primitives like
modern conventional OSes have)
On a microkernel, a purely stream-oriented IPC transport layer will
have better performance when dealing with bulk unstructured data than
a structured RPC transport layer with dynamic marshalling invoked on
every message (for servers that need RPC with dynamic marshalling, the
transport layer can easily support a type of file that preserves
message boundaries but otherwise has standard Unix semantics)
A purely stream-oriented IPC transport layer is simpler than one with
dynamic marshalling and has less attack surface
All services in the system can be extended, overridden, and exported
through the same mechanism (this includes making all parts of a purely
file-oriented OS network transparent for basically free)
In some cases a higher-level service that extends another one doesn't
have to fully intercept all parts of the underlying interface (e.g. if
the underlying interface has multiple files and only some need to be
overridden, or possibly if some messages are treated as opaque)
1607
days inactive
1608
days old
5 comments
5 participants
participants (5)
-
Andrew Warkentin -
Bakul Shah -
Dave Horsfall -
Norman Wilson -
Warner Losh