[9fans] Plan 9 future (Was: Re: Are the Infernospaces gone?)

[Lucio De Re lucio@proxima.alt.za]

On Wed, May 10, 2000 at 08:51:25AM +0000, Douglas A. Gwyn wrote:
>
> In actual use, this behavior was much nicer than the original
> behavior (that merely passed cd's argument to kernel chdir() and
> had to reconstruct a path for "pwd" by massive kludgery in user mode)!
>
Contrary to Rob's request, at this point, except...

> >From that experience I concluded that the current working directory
> ought to be maintained by the kernel as a path, not (just) an inode
> index, and chdir() should canonicalize the path as described above.
> (There doesn't seem to be any need to test whether the target node
> exists; that will turn up later when a file is opened.)  getcwd()
> then has a near-trivial implementation, and user-mode utilities
> can implement "cd" and "pwd" by simply making system calls.
>
Sounds cool.  No harm keeping the inode information at the same time,
as long as there's some way to tell that it is valid.  Then one also
gets backwards compatibility.  I like this concept, it broadens one's
scope without cramping one.

More interestingly, it neatly removes the need for ".." altogether,
doesn't it?  And any ambiguity this may lead to. ".." can then
become merely a notation, extendable: "..." for two levels up, etc
(I think Novell first thought of that) and overloadable (hm, what if
I create a ".." or "..." entry to point to where _I_ want to go?!

> Sorry for the long story, but I think it has some bearing on the
> question of the "right" way to do "bind" etc.

Definitely food for thought.  Other than kernel size, I see little
reason why this was not considered in the original specification
(except lack of vision long before hard and soft links were
introduced), and even less reason for not going in that direction.

++L