Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!caen!uflorida!gatech!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.os.misc
Subject: Re: What constitutes a good OS?
Message-ID: <43791@nigel.ee.udel.edu>
Date: 5 Feb 91 20:09:36 GMT
References: <5461@auspex.auspex.com> <42683@nigel.ee.udel.edu> <5685@auspex.auspex.com>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 52
Nntp-Posting-Host: estelle.ee.udel.edu

In article <5685@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>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.

Or my eyes. :-)

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

OK.  But at what level do you put the "container" object?  Disk blocks?
Arrays of bytes?  Arrays of resizable records? Entire database relations?
This is my quandry. Why are "arrays of bytes" OK to go in the kernel, but
"arrays of resizable records" not?

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

Because the KSAM code wants to be able to allocate blocks for the file
from a per-file-system pool also.  It also wants access to the block
buffers that are in kernel memory.  It also wants to be able to block
user processes to keep them from both updating these files at the same
time. All the arguments about "insert()" and "delete()" apply equally
well to KSAM files.  You can build these in "userland" but then you
have all the same problems that the "insert()" and "delete()" additions
caused. With a simpler "container" basic access method (say, allocate,
deallocate, read, and write individual disk blocks, as well as locking
of arbitrary conditions (file=xxx, key=yyy or zzz) rather than byte
offsets within files) it could be efficient to implement all this stuff
at the user level.  At a higher level, the need to go "under" would be
less common and the system would overall be more efficient. But right
now the filesystem in UNIX is efficient for neither the hardware nor
the software.
			    -- Darren

-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, 
      Formal Description Techniques (esp. Estelle), Coffee, Amigas -----
              =+=+=+ Let GROPE be an N-tuple where ... +=+=+=