Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!ames!amdcad!light!bvs
From: bvs@light.uucp (Bakul Shah)
Newsgroups: comp.unix.wizards
Subject: Re: is this wise?
Summary: Yup.
Message-ID: <1989May6.133452.465@light.uucp>
Date: 6 May 89 20:34:49 GMT
References: <378@chessene.UUCP> <53756@uunet.UU.NET> <16437@rpp386.Dallas.TX.US> <53862@uunet.UU.NET>
Reply-To: bvs@light.UUCP (Bakul Shah)
Organization: Bit Blocks, Inc.
Lines: 61

In article <53862@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes:
> [...]
>I can see it now:
>
>	getpwuid(213) becomes open("/dev/password/213")
>	gettimeofday() becomes open("/dev/clock")
>	etc.

This is not as silly as it seems.  In fact it can open up some
exciting possibilities.  Think of `open(<path>)' as a mapping
from a name space to object handles.  Once you get a handle, you
can invoke operations defined by that object.

A better idea is to have `obj_open(dir, path)', which takes a
directory handle + path and returns a handle.  A directory need
not be the familiar unix directory; it can be any object with a
function `lookup', which maps a name to an object.  Now we can
characterize obj_open with the following equalities:

    obj_open(dir, "foo") == dir->lookup(dir, "foo")
    obj_open(dir, "x/y/z") == obj_open(obj_open(dir, "x/y"), "z")
    obj_open(dir, "x/y/../z") == obj_open(dir, "x/z")

Now open can be defined in terms of obj_open:

    open("/foo") == obj_open(root, "foo")
    open("foo")  == obj_open(cwd, "foo")

And gettimeofday:

    gettimeofday(...) == open("/dev/clock")->read(...)

We can fix some obvious holes in this scheme and then extend it
to handle symbolic links, open options, adding new maps to a
directory etc.

>By your argument, we change everything to use open. (And if you
>think the kernel is big now, wait until you move most of the
>userlevel networking code into it)
>
>--rick

Not everything can use open but many of the major subsystems
can.  By doing so we make it easier to understand and extend
them.  New user level subsystems can be added if there is an
interface for registering new services and dispatching of
requests back to the user level objects.  This is preferable to
the current haphazard collection of library routines (which can
be built using this facility for compatibility).

As for the kernel, it can be made to *shrink* by moving things
out of it.  Once access permissions are checked for and a client
(caller of open) is hooked up to a server (object whose handle
is returned by open), the kernel has no business of being in the
middle.  I'd move almost everything out of it.

I don't think bsd4.3 or SVR3 can be transformed into something
like this without mega-hackery but perhaps a from-scratch
implementation of unix++ (using c++)....

-- Bakul Shah <..!{ames,sun,ucbvax,uunet}!amdcad!light!bvs>