Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!snjsn1!aconcagua!johnb
From: johnb@aconcagua (John R. Bashinski)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Keywords: GNU OS features kernel fun!
Message-ID: <1049@snjsn1.SJ.ATE.SLB.COM>
Date: 26 May 89 03:57:11 GMT
References: <106326@sun.Eng.Sun.COM>
Sender: news@SJ.ATE.SLB.COM
Reply-To: johnb@sj.ate.slb.com (John R. Bashinski)
Organization: CIS, Schlumberger ATE, San Jose
Lines: 156

In article <106326@sun.Eng.Sun.COM> bitbug (James Buster) writes:
>What kinds of things should be in the GNU Kernel?
>What kinds of features or design rationale should it use?

Well, I've never done any OS design, but nobody can claim I'm not
opinionated :-)...

The most important thing is to build a framework in which things can be
added later. It's not important to provide a lot of user functionality
that's not in existing systems. What is important is not to make any
decisions that'll prevent somebody else from adding it later. That'll
be difficult enough. The module interface designs will probably be the
most enduring part of the whole system.

Make the system lean and, and make it configurable, so people can choose only
the code they need. Allow as much dynamic reconfiguration as possible. If
it's not too hairy, support SysV.4 device drivers and streams modules. Put
emulation for BSD calls (or SysV calls, or whatever) in libraries, not in
the kernel, unless it *really* needs to be there.

It's important to support multiprocessors and allow for tightly-coupled
distributed systems. No non-reentrant code. Good locking and synchronization
primitives, available both within the kernel and outside it, probably
message-based. Do this stuff right, allow user processes to run in kernel
VM space, and keep your interrupt handling clean, and you can go a long
way toward letting somebody add a real-time scheduler to the system later.

Multiple threads of control: Decouple threads of control from address
spaces. It should be possible to have more than one thread in a given
address space, and to have the scheduler manage that for you. It might
be nice to be able to start a thread of control in *somebody else's*
address space (maybe even in kernel address space), to manipulate other
address spaces and other threads in other ways.

Extensions to the filesystem name space: Everything (from the user's point
of view) should be a file.  That means real files, devices, pseudo-devices,
network connections to other machines, VM address spaces other than your
own, data about threads, scheduler control, everything. When you open a
file, you establish a connection to some kind of object. It may be
implemented by kernel code or by user-mode code. You can send data to it,
read data from it, maybe seek it, and maybe map it into your address space.
What it does with your data is type-specific.  You can also send it
type-specific commands, using something like ioctls, but more general;
perhaps typed reads and writes. It can generate events that wake you up
and/or signal (or something better than signal!) you when it has data for
you. It should be possible for user-mode code to "get behind" mount points,
and maybe even disk "files" and "directories", and provide services. It
should be possible to have the trailing part of a pathname passed to
whatever implements a "directory" for further processing. This probably
means that there need to be directory access mechanisms built into the file
system primitives, so these objects can tell programs what's available in
the name space. There probably also needs to be some kind of unique object
identifier that can be a successor to the inode.

>File system:	SysV vs Berkeley? Something better?
>		Embedded file types? >32-bit file offsets?

The Berkeley file system (perhaps slightly augmented) would be fine for
disks, at least for now. Heathen file systems without symbolic links would
not be adequate :-). It's more important to build a flexible operating
system foundation than to design a new disk structure. The file system
definitely shouldn't worry about the type of the data in a file until
much, much later on.

>Security:	ACLs? Get rid of root? Security monitors? Auditing?
>		Provably secure(A1)?

There's no need for ACL's, or A1 security, or auditing, or whatever just yet.
There *do* need to be hooks for providing these things. That basically means
that a reference monitor interface needs to be designed, and that the system
needs to channel requests for access through it. There needs to be a clear
definition of what objects have privileges, what operations may require
privileges, how privileges get passed around, how to *prevent* privileges
from getting passed around, and so forth.

Glimmerings of a structure: Privileges belong to threads of control; each
thread has a privilege list. A privilege is represented by a unique
identifer, which subsumes the functions of both UNIX UIDs and GIDs.
Certain of a thread's privileges are marked as corresponding to real
and effective UNIX UIDs and GIDs. Privileges in a thread's privilege
list have other binary attributes, things like "can/can't be delegated",
"can/can't be given up", "pass/don't pass on fork", and so forth. Some
attributes can be modified by the thread, others can't. A reference
monitor gets called by whatever implements a file/object to examine
opens, closes, reads, writes, and control operations. The reference monitor
is allowed to issue a capability identifier of some kind at object open,
and can restrict how that capability can be delegated.  Whenever an operation
is attempted on the opened object, the object implementation passes the same
capability to the reference monitor as part of the information about the
operation. It may choose to revoke a capability at any time.

Issues: When you open a "file", does the object at the other end get your
privileges by default? Can you change the default? What code is allowed
to issue privileges?

>Scheduler:	Real-time support? Task-driven? Event driven?
>		Direct brain hookups:-)?

Start with the simplest scheduler you can get away with... and make it
easy to replace. Real-time people seem to like to write their own schedulers
anyway.

>Virtual Memory:	Should GNU run on non-VM machines? Algorithm ideas?
>		How general (map *everything* into VM space, like Multics)?
>		Shared libraries?

It would be nice to have a well-defined subset of the system that could
be run on a non-VM machine, but the full-blown system needs to offer
functions that you can only get with virtual memory.

*Everything* should be in the file system name space... and it should be
possible to map anything sensible from the file system into your VM space.
That doesn't mean that everything needs to be mapped by default, though.
There needs to be support for wiring down pages, user-defined paging
strategies, read-only mapping under user control, and maybe copy-on-write
(there definitely shouldn't be any choices made that would preclude
copy-on-write).

Shared libraries (which are a good idea) can be supported in user code.
No need to clutter the kernel with anything more complicated than file
mapping.

>Networking:	NFS? RFS? Something better?
>		Interfaces: Streams? TLI? Something better?
>		TCP/IP? OSI? SAA/SNA:-)?
>		RPC Services? What kind?

My personal desires: Definitely TCP/IP. Definitely NFS. Maybe RFS. Maybe OSI.
Make it easy to add stuff. Use Streams/TLI (perhaps somewhat extended) for
the real networking code, but provide a socket emulation library.

>Overall Design:	What nice ideas from other OSes could we use?
>		Multics? VMS? VM? DG/OS?
>		Fault tolerance?
>
>How about this? Make everything a user process which serves
>a resource to a client. Resources include the CPU (scheduler),
>memory (VM), disk (file system), network (sockets, etc),
>serial lines (terminal handlers), etc. Each server determines the access
>method and security criteria for its service. Make no arbitrary policy
>decisions regarding a service! Don't like the VM server? Replace it! You
>could have a security monitor provide a security policy on behalf of
>your file system or IPC mechanisms. If you have no need for security,
>don't run the monitor.

I'm not sure how you'd put the scheduler in a user process, but this
is basically a good way to go... provided that you can get decent performance
out of it. Some of these processes could probably run in the kernel's address
space. I think that putting things in the file system name space is a good
way to provide access to the resource managers for everything but the
two really essential resources, CPU and memory, and even for some of the
fine control over those.

-- 
John R. Bashinski   johnb@sj.ate.slb.com   {amdahl,decwrl,uunet}!sjsca4!johnb
+1 408 437 5218        M/S 32-0846, 1601 Technology Drive, San Jose, CA 95110