From: lithgow@uslp.UUCP
Newsgroups: comp.sys.acorn
Subject: Re: Acorn
Date: 14 Apr 92 03:34:06 GMT

[In message "Re: Acorn", Philip R. Banks writes:]
>lithgow@uslp.UUCP writes:
>> It was amusing to see that one of the 'some future release' enhancements
>> was stackable filesystems. Acorn have only had that technology for three
>> or four years (with a three level stack for ADFS, RAMFS, etc., and two
>> level stack for most other FS's), and it will be three or four years
>> before UNIX gets it.
>
>   Stackable FS's? What doest thou meanst Malcolm? Thou doest speakith with
>a strange tongue.... :-)

Sorry, it's UI's language, not mine. I would have called it
'of-course-it-should-be-done-that-way-only-Americans-would-think-it-is-
a-wonderful-new-technology Filesystems', or the prefered Acorn name:
'doesn't-everyone-do-it-that-way Filesystems'. ;-)

I've already mailed a reply on this question, so, here it is: (BTW,
apparently Sun and others have a different type of 'stackable' FS's,
which are much less useful.)

The filesystems themselves don't stack (an interesting idea, what is it
used for?), but the code does. For example, the cacheing code can be
built into one layer of the stack, and shared by all the filesystems
below it (or above it, however you want to view the stack). (Damn, UNIX's
method of calling virtual file spaces 'filesystems' gets confusing in
this sort of situation.)

Acorn does this by FileSwitch supporting all FS independant code, then
FileCore supporting all media independant code for ADFS-like FS's, then
ADFS (etc.) supporting media dependant code. Of course, it is possible to
put more or less layers in there.

Some long-distant UNIX will have this feature (this is not proprietary
info, you can find it in the UI Roadmap, which is given to journalists,
etc.) SVR4.0 already has a virtual file-switch node, but it simply
switches the entire set of interfaces from one set of FS code to another,
depending on what sort of FS you are accessing at the time, I believe.
Acorn's system is cleverer than that, thank goodness. (On the other hand,
SVR4.0 does use the multi-FS capability in a fuller fashion, it even has
an FS for accessing processes. No, I take that back, they use the
multi-FS's in a *different* fashion -- Acorn also makes plenty of use of
them, after all, printer: is an FS!)

Jon (who asked the question this is a reply to) replied that this would
slow things down, and my answer is: only if things were done incredibly
stupidly!

Why? For the very same reason that normal code isn't terribly slowed by
writing stuff in a structured, procedural fashion. After all, if
FileSwitch is asked to do, say, a *count, it uses the underlying routines
of the FS's just like subroutines. And if you call the OS_GBPB SWI,
FileSwitch indirects it straight to the appropriate routine in the FS
code (in FileCore for ADFS's case, I believe, but I have a 50% chance of
being wrong, ADFS has even lower level 'subroutines' I believe). Working
out which FS code to indirect to isn't difficult, either, since the FS
information will be stored with all the other info pointed to by the file
handle, I presume, and each (instantiation of an) FS registers a table of
pointers with FileCore, I know.

-Malcolm    lithgow@uls.com    These are my opinions, nothing more nor less.