Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.os.misc
Subject: Re: What constitutes a good OS?
Message-ID: <5331@auspex.auspex.com>
Date: 17 Jan 91 18:48:15 GMT
References: <41754@nigel.ee.udel.edu> <5298@auspex.auspex.com> <41907@nigel.ee.udel.edu>
Organization: Auspex Systems, Santa Clara
Lines: 104

>>	2) some file system types for UNIX might well *give* directories
>>	   indices - directories generally aren't plain-text files in any
>>	   case;
>Not any more. They used to be. This broke a lot of programs at the time.

Wow!  You used UNIX back before 1975? :-)

Directories weren't plain text files back in V6 (which was around in the
1975 time-frame); a directory entry was a 2-byte binary inumber followed
by 14 bytes of possibly-null-terminated file name.

You may be thinking of the transition from the V7 file system to the
4.2andupBSD file system, but that wasn't a change from plain-text-file
directories to non-plain-text-file directories, it was a change from one
non-plain-text format to another.

>>	   [...] but, if the
>>	   program that edits them doesn't know the format of the file,
>>	   that'd have to be the case *anyway*, unless you had, as an
>>	   attribute of the file, something that told the keyed access
>>	   package or the editor how to scan the text of a line to
>>	   figure out the key.
>Exactly my point. If keys are in the filesystem as opposed to a library,
>then every program has access to that information automatically.

No, not exactly your point at all, as far as I can tell.  *My* point is
that in order to have "/etc/passwd" as an indexed file, but one that you
can edit as a plain-text file, some indication of how to generate the
key for an entry in that file would have to be recorded in or with the
file; merely having "the filesystem" support keyed files isn't
sufficient.

This also raises questions of what "the filesystem" is, as opposed to
"a library".  In RSX-11, as I remember, the Files-11 ACP's only support
of records, keys, etc. was that it would store various file attributes
in the file header, and let user-mode code retrieve and change them. 
The model presented to user-mode code, at the QIO level, was that of an
array of blocks.  The stuff that implemented records, keys, and the like
was, in fact, a user-mode library.

So, in RSX-11, are keys in "the filesystem" or in "a library"?

In VMS, I think the only difference is that the RMS library runs in
executive mode.  Does that change whether keys are in "the filesystem"
or "a library"?

Were all UNIX systems to come with an ISAM library - with the C-ISAM
programmatic interface, say - and were all UNIX systems to have a file
system that permits storing and retrieving of attributes the way
Files-11 does, and were all the ISAM libraries to use that, would keys
in "the filesystem" or in "a library"?

>It has been my experience that bugs in the kernel get fixed faster than
>bugs in the non-kernel packages because more people complain and bugs
>are generally more catastrophic and there is less often a fall-back
>program. This is not to say that I think it is a good idea.

If you didn't think it was a good idea, why did you present it as part
of your argument against the Plan 9 window system?

>Right.  Since the filesystem *is* part of the privledged supervisor in
>UNIX, then the question is moot.

Again, the question of "what is 'the filesystem'?" comes to mind.

Imagine a UNIX system (this is inspired by my understanding of the way
Apollo systems work - but I'm not sure whether code implementing file
types is in any way privileged or not; it might be) with run-time
dynamic linking.  (SunOS 4.1[.x], S5R4, probably OSF/1 - and also
Domain/OS, as you might guess from the previous parenthetical note....) 
Let's also add one small feature to the current UNIX file systems: a
32-bit or 64-bit arbitrary attribute for every file, with kernel calls to
set and get that attribute.  The kernel doesn't interpret it at all. 
(There's probably room in most 4.2andupBSD file system inodes for this.)

Now, imagine that "open()", "close()", "read()", "write()", "lseek()",
"ioctl()", etc.  didn't trap directly into the kernel.  Imagine them as
library routines - shared library, if that's what it takes to move them
out of "a (mere) library" :-) - which get at the raw data in the file
using something like "mmap()".  "open()" might have to sneak around the
back and do the standard trap into the kernel around which "open()" is
normally just wrapped.

The "open()" routine would read the attribute in question, and use it to
find some dynamically-loadable object that implements the "read()",
"write()", etc. operations on that file.  Some file types could have
additional operations implemented on them, such as "read by key".

This could even handle the "/etc/passwd" problem - you'd add a "password
file" file type, wherein "read()" would just give you the file's data as
is (or perhaps give you only one line at a time), and "write()" would
have to update the keys.

Now, in this system, what is "the filesystem"?  Is it the code - which
in this case, let us say is still in the kernel - that supports a
namespace, and "bags of bytes", with associated attributes, to which the
names in that namespace refer?  Or is it that code *plus* the
"open()"/"read()"/"write()"/etc. implementation, which supports text
files, keyed files, etc., etc., etc.?

>The filesystem, which is a library in AmigaDOS.

So are the file system's features in AmigaDOS in "the filesystem" or "a
library"? :-)