From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 10 May 2000 11:49:42 +0200 From: Lucio De Re lucio@proxima.alt.za Subject: [9fans] Plan 9 future (Was: Re: Are the Infernospaces gone?) Topicbox-Message-UUID: a9b2cd14-eac8-11e9-9e20-41e7f4b1d025 Message-ID: <20000510094942.CJL84ujbKVE2qKa3v_EsTQuUC0Fm6R9lmFcy1L_-F7U@z> 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