What kinds of things would you want in the GNU OS?

[Bakul Shah]

In article <40062 at cmcl2.NYU.EDU> edler at cmcl2.UUCP (Jan Edler) writes:
>In article <1989Jun3.004854.18111 at light.uucp> bvs at light.UUCP (Bakul Shah) writes:
>>	open("/etc/passwd", ...)
>>and
>>	open("src/os", ...)
>>
>>can be replaced by calls like
>>
>>	obj_open(root, "etc/passwd", ...)
>>and
>>	obj_open(cwd, "src/os", ...)
>>
>
>We considered extending the kernel/user interface in something like
>this way, but tentatively rejected it.
	[edited]
>We decided that it was better to extend the pathname notion, than to
>extend all system calls taking pathnames so they take a handle too.
>The reason for this preference ... was the
>desire to treat handle+path specifications as simple strings that can
>be used exactly the same way pathnames have always been used.
> ...
>            My current preference is to say that "/@" at the beginning
>of a pathname, followed by a file descriptor number (as a string of
>digits) and a "/", means to take the object referred to by the file
>descriptor as the search starting point.
	[edited out a list of relevant issues/problems]
>Any comments?

1.  If the goal in introducing the ``/@nnn/foo/bar'' syntax is to
    efficiently reference files in any of several frequently-used
    directories, then the number of new problems introduced by the
    new notation seems like too heavy a price to pay for it.

2.  I am not sure I understand the benefit of keeping handle + path
    spec. as simple strings.  I am hoping for something stronger
    than ``that is how pathnames have always been used''.

3.  A naming scheme like yours can be implemented on top of a
    simpler scheme (like obj_open) and entirely in user mode.  IMHO
    this is a Good Thing (atleast until you iron out all the
    problems in your scheme :-)

4.  You need not objectify all system calls.  If all you want is the
    convinience of multiple current working directories, you can
    simply add a new syscall for obj_open() and replace open()
    syscall by open() library routine.

At this point I am not too keen about any new feature that
*increases* the size of a kernel.  Sys V / 4.3 BSD kernels are
already too big and still, they are limited.  In their place I would
like to see a simple kernel that I can completey understand and keep
in my head without having to flush out everything else.  This kernel
should implement a small set of very simple mechanisms from which
existing interfaces and more can be built.  I believe an object
kernel + a user-level shared library for compatibility can meet this
goal.  Now all I need is some time and resources to prove this....

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