Path: utzoo!mnetor!tmsoft!torsqnt!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: <5685@auspex.auspex.com>
Date: 2 Feb 91 03:14:54 GMT
References: <42488@nigel.ee.udel.edu> <5461@auspex.auspex.com> <42683@nigel.ee.udel.edu>
Organization: Auspex Systems, Santa Clara
Lines: 51

>(Note: in the following discussion, when I say "library" I mean
>user-mode application library, dynamic or not. When I say "kernel" or
>"filesystem" I mean a filesystem that has access to presumedly
>privledged information in the kernel such as device buffers, disk
>allocation bitmaps, etc and also has the ability to prevent or
>otherwise control process preemption and/or resumption. "kernel" does
>not necessarily mean resident, nor does library mean statically
>linked.)

...

>Anyway, I think that makes some good points, and I would be interested
>in any discussion this may raise.  I would be especially interested in
>hearing why putting such functionality is actually *better* than
>putting it in the kernel, rather than simply possible, which is all
>I've heard up to now.

If you think you've heard from me any claim that a *container*-level
object of the type you describe is better implemented outside a
privileged subsystem than inside one, get your hearing checked.

I've already drawn the distinction between a "container" and an object
with more structure; for instance, the arrays of bytes or blocks
implemented by many OSes (UNIX, RSX-11, VMS and, I think, OS/360 and
successors) in the privileged-subsystem portion of their file systems
are "containers", and text files, sequential files, indexed files, etc.
are the more structured objects stuffed into those containers.

It's somewhat similar to the structured address spaces provided by the
privileged-subsystem portion of some OSes (e.g., more modern versions of
UNIX) and various stuff that can be built atop it, often in userland;
for example, many UNIX systems let you map files into memory with
"mmap()", and then that can be used by such as shared library/dynamic
linking mechanisms, multithreading packages (for multiple stacks), etc..

Given that your new kind of container probably wants to be able to allocate
blocks for the file from a per-file-system pool which would be shared by
other processes (and possibly other users), I have no problem with
implement low-level primitives such as your "insert()" and "delete()"
primitives inside a privileged subsystem.

However, I don't see any point to putting stuff you build *on top of*
that container, e.g. KSAM files, into the kernel, unless they need
access to some shared resource that should be denied non-privileged
code.

>Editors no longer have to suck up the entire file and blow it back
>out to add one character to the first line.

Of course, for a lot of files, that's no real win; lots of text files
are quite small.