Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!wuarchive!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.os.misc
Subject: Re: What constitutes a good OS?
Message-ID: <41907@nigel.ee.udel.edu>
Date: 16 Jan 91 21:30:40 GMT
References: <1991Jan15.084127.4044@kithrup.COM> <41754@nigel.ee.udel.edu> <5298@auspex.auspex.com>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 65
Nntp-Posting-Host: estelle.ee.udel.edu

In article <5298@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>	1) the keys you *want* on the aforementioned files aren't line
>	   numbers, they're things like the user name, the user ID, the
>	   terminal type, etc;
Right.  Line numbers are a special case of a more general feature.
>
>	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.
>	   [...] 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.
Compare this to file locking: if it is in the kernel, then all
programs will respect a lock. If it is in a library, then I
can still change things under your program in spite of the fact
that your program has a lock on the file. Which is `better'?

>I.e., kernels don't have bugs?  I don't believe that.  

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.

>>Basically, that pretty much sums it up.  I think relatively minor
>>additions in the kernel of UNIX (primarily file handling)
>"kernel" in the sense of "privileged supervisor" or "core set of OS
>services"?  The object-oriented scheme suggested by some postings might
>be better implemented, to a large degree, outside the privileged
>supervisor.

Right.  Since the filesystem *is* part of the privledged supervisor in
UNIX, then the question is moot.  However, it does lead me to my next
flame-bait topic: What *should* be in the kernel? What *must* be in the
kernel?  Is it possible to come up with a definitive minimal set of
services that *must* be in the kernel of a multi-use, multi-tasking,
multi-user computer OS? For example, we can see that authentication
need not be a privledged operation (see Kerberos).  However, I don't
know of any filesystems that allow the user to specify his own routines
for ACLs on files; rather, you need to make the filesystem an active
entity (like a mail server) and have the server call Kerberos.

For example, some of the things that are in the UNIX kernel that
are not in other OSs:

Closing file handles upon exit, which was done by the shell in CP/V.
Core dumps, which were done by the shell in CP/V.
The filesystem, which is a library in AmigaDOS.
Device drivers, which are libraries in AmigaDOS and several other
systems.
Executable loading (exec()), which is done by the shell in MS-DOS.

Can somebody give me a good reference on Mach or Multics? Thanks in advance!
	     -- 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 ... +=+=+=