Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!pyramid!weitek!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: <1989Jun5.112231.21303@light.uucp>
Date: 5 Jun 89 18:22:29 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> <1989Jun3.004854.18111@light.uucp> <10364@smoke.BRL.MIL>
Reply-To: bvs@light.UUCP (Bakul Shah)
Organization: Bit Blocks, Inc.
Lines: 35

In article <10364@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <1989Jun3.004854.18111@light.uucp> bvs@light.UUCP (Bakul Shah) writes:
>>	obj_open(cwd, "src/os", ...)
>>In effect the concept of `current directory' disappears ...
>
>Yup, you got it.  Using a null "existing handle" argument gets a local
>top-level handle.  If you think how this can be implemented (handle is
>a kernel data pointer), then consider how the kernel implementation of
>"pathname" parsing for obj_open (which I think of as "subopen") can
>take advantage of the uniformity, you'll see some of the other potential
>advantages.  This seems to nicely accommodate portals, remote object
>access, and so forth.

Three comments.

1.  If the return value and the first arg. to obj_open have the same
    type, you can do things like `cwd = obj_open(root, "etc", ...)'.
    This type should be same as an ordinary descriptor (an already known
    quantity) instead of a kernel data pointer.

2.  Use of a `null "existing handle" argument' would force the kernel to
    maintain a special handle which does not seem like a good idea.  It
    is equally easy (and less magical) to let each process inherit the
    handles it needs.  You may say the kernel already maintains u_cdir
    (cwd) and u_rdir (root) inode ptrs so what is the big deal.  My
    point is that we don't need them so why keep them.  IMO kernel
    maintained variables are even worse than global variables.

3.  Access to portals etc. can be very useful but obj_open (or subopen)
    by itself won't do it.  The real key is in how it is plugged into
    the modules implementing portals, remote objects and such.  I see
    obj_open as one step on the way to a *small* object kernel.  Anyone
    working on such a thing?

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