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

[Jan Edler]

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", ...)
>
>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 considered extending the kernel/user interface in something like
this way, but tentatively rejected it.  Our goal wasn't to "objectify"
the system, or to move namei out of the kernel, or anything like that.
It was simply to generalize the notion of cwd, so that a process can
efficiently reference files in any of several frequently-used directories.

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 wasn't to avoid modifying all those
system calls, or to avoid needing a compatibility library.  It was the
desire to treat handle+path specifications as simple strings that can
be used exactly the same way pathnames have always been used.

We've been a bit indecisive about the exact form of pathname
extension.  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.

There are several issues relevant to this design, including:
- Prevention of real entries in "/" like "@nnn".  This is aesthetically
  unfortunate, but I don't think it's too serious.  How many systems out
  there have entries in / like this?
- Inability to transparently splice "/" on the front of a pathname.
  This is easily fixed by allowing 1 or more "/" chars in front of the "@".
- We have to decide what to do about paths like "/foo/../@nnn/bar"
  and /@rootfd/@nnn/bar:  my preference is that they are undefined --
  /@nnn only has special meaning at the beginning of a path.  But it
  wouldn't be too hard to make such paths work in the "expected" way.
- "Dangling reference" confusion resulting when a program closes a
  file descriptor and later uses a pathname dependent on that fd.
  Of course the serious problem is when the fd has since been reassigned
  by a subsequent open.  There is no better fix for this problem than
  to insist that programmers not close descriptors they didn't open
  (except for 0,1,2).
- The need to convert back and forth between strings and integers is
  annoying.
- A new open flag (O_EXEC), as previously discussed in this newsgroup,
  might be useful when dealing with file descriptors of directories.
- Changing the lead-in string from "/@nnn" to "/@/nnn" might be
  advantageous because /@/ could be implemented as some kind of mount
  point on some systems, although this would be slower than more
  direct implementation strategies.
- We have to decide about the degenerate case, opening "/@nnn"
  (i.e., nothing after the fd): does the resulting file descriptor
  share the same file pointer as the original?  This question must
  also be addressed by /dev/fd/nnn implementations (do they all do
  the same thing in every case?).

I'm sure I've forgotten some additional issues.
Nevertheless, the ability to express such "handles" as part of pathname
strings seems valuable.  We can define conventional environment strings
like $cwd, $root, and others, containing the file descriptor numbers
to be inherited over exec; this removes the need to define special
meaning for additional fd numbers, beyond 0,1,2.

Any comments?
Jan Edler
NYU Ultracomputer Research Laboratory
edler at nyu.edu
...!cmcl2!edler
(212) 998-3353