Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!bloom-beacon!usc!elroy!ames!amdcad!light!bvs
From: bvs@light.uucp (Bakul Shah)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Message-ID: <1989Jun3.004854.18111@light.uucp>
Date: 3 Jun 89 07:48:51 GMT
References: <106326@sun.Eng.Sun.COM> <4315@ficc.uu.net> <338@arc.UUCP> <10332@smoke.BRL.MIL> <4346@ficc.uu.net> <10343@smoke.BRL.MIL> <1232@pkmab.se> <10357@smoke.BRL.MIL>
Reply-To: bvs@light.UUCP (Bakul Shah)
Organization: Bit Blocks, Inc.
Lines: 45

In article <10357@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <1232@pkmab.se> ske@pkmab.UUCP (Kristoffer Eriksson) writes:
>>Aren't you going to tell us what your scheme is?
>
>I'd rather not, at least not until the research types have finished
>working it over, but the basic notion is "it takes a handle to get a
>handle".  If that doesn't help, sorry -- wait until later when I have
>time to write it up (assuming it still seems like a good notion then).

Seems like you are advocating giving explicit handles for things
like root, current dir. to a user process instead of the current
`hidden' handles (which exist in the u. struct and are managed by
the kernel).  So then calls like

	open("/etc/passwd", ...)
and
	open("src/os", ...)

can be replaced by calls like

	obj_open(root, "etc/passwd", ...)
and
	obj_open(cwd, "src/os", ...)

In effect the concept of `current directory' disappears as one can
keep any number of directory handles around and walk relative to
them.  Which directories can be walked depends upon the initial
set of handles + directories reachable from this initial set.

We can generalize this behavior by replacing all Unix system calls
that depend on objects managed by the kernel on behalf of the user
with system calls that require explicit handles and let the user
handle them himself.

If this is sort of what you have in mind, I like it.

I'd go one step further and throw away the current flat system-
call interface.  Instead I'd define what kinds of objects are
implemented by a Unix like OS and define a minimum set of
operations for each kind.  Then every system call is a request for
a specific operation, made on an object whose handle is held by
the user process.  A compatibility library can be built to allow
running of standard Unix programs atop this object oriented Unix.

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