Newsgroups: comp.sys.acorn
Subject: Re: Acorn
From: banksie@khantazi.welly.gen.nz (Philip R. Banks)
Date: Tue, 14 Apr 1992 23:26:30 +1200
Reply-To: banks_p@kosmos.wcc.govt.nz
Organization: My Arc.

lithgow@uslp.UUCP writes:

> 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!)

   So, correct me if I am wrong, is that all Unix FS's don't share
*any* code at all right?

<Falls in corner and laughs alot.>

   Ya know the more I find out about Unix the less I like it...

> 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.

   It is interesting to note that this sort of thing has been taken to a
higher level in RO3. The internals of RO3 seem now to work totally on *full*
pathnames at the FS level. All %,^,&,etc... symbols are now handled at the
FileSwitch level (I think, it could be FileCore...). So all FS's now ever
need to handle is the simplified case of a full path for all file
references. Of course this results in smaller FS code size for all new FS's
but the really cute bit is that this system still works just fine with old
RO2 style FS's - they are just a bit larger than they need to be...

   It is also why in RO3 typing a *Cat. will produce the directory listing
will a set of full paths at the top to describe things like CSD,Lib etc...

  Yet another example of Acorn not doing anything wonderful in RO3 again....
:-)

    Philip

--
Philip R. Banks                                                         @@@@@/|
Syntax: mail <banks_p@kosmos.wcc.govt.nz|banksie@khantazi.welly.gen.nz> @@@@/#|
                                                                        @@@/##|
What price the crown of a king on his throne,                           @@/---|
When you're chained in the dark all alone?  ---A.P.P.                   @/    |