From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <775b8d190811101750q24a7650fu5500f54b0771cffc@mail.gmail.com> Date: Tue, 11 Nov 2008 03:50:53 +0200 From: "Bruce Ellis" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <1226365206.17713.390.camel@goose.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1226365206.17713.390.camel@goose.sun.com> Subject: Re: [9fans] Do we have a catalog of 9P servers? Topicbox-Message-UUID: 3acff226-ead4-11e9-9d60-3106f5b1d025 Why does your build fail? Lack of vision to the extreme resulting in a completely horrible way of building things that has grew and grew to something that not even its mother could not love. In some sense it's good that it fails. If you want to build things that way then don't use plan9. Seriously. The simplest program is now entangled in the most horrendous config/build mess. Why? Because that's how you do things. No!!! "Hideous, horrible!" - as a friend at the Labs would shout (not about CS, he was a physicist). As for mknod, I don't think it's worth trying to keep that alive, let alone breaking plan9 to do it. brucee On Tue, Nov 11, 2008 at 3:00 AM, Roman V. Shaposhnik wrote: > On Tue, 2008-11-11 at 00:14 +0000, Charles Forsyth wrote: >> >But wouldn't you agree that files kept on a remote POSIX file system is >> >an important and common class of remotes resources for which we don't >> >quite have a consensus on how to use 9P? >> >> yes, but both your examples are things of purely local significance. > > Sorry I'm confused, which examples are you talking about? Anyway, for > the sake of this conversation lets focus on: using 9P as the means to > access files on a remote POSIX filesystem. > >> the symbolic links point to something local (or not), and the major/minor >> numbers are decidedly only local (since they index a kernel's data structures!). >> sorry, to which they refer. > > This approach seems to be flawed on two accounts: > 1. it forces the server to resolve symlinks and special > nodes, without an option for the client to do the same. > That prevents cross-tree symlinks and nodes as the > points of rendezvous *on the client*. IOW, the following > will not work: > $ mknod /test p > $ echo test >> /test & > cat /test > I can buy a point of view that reading on a node that happens > to be a character device should really bring the data from > the remote server's device attached to that node. However, > that point of view is much more difficult to sell for > FIFOs. > > 2. It doesn't let manipulate these special files. IOW, > readlink(2) fails and so does mknod(2)/symlink(2). > > For the practical application of 9P a failing symlink(2) is a big > source of problems. > > In fact, "why does my build fail" was the first question that people > asked me once I demonstrated my prototype of drawterm written in > Java. It fails because it tries to symlink within a tree that > is exported. > > Thanks, > Roman. > > >