From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 11 Nov 2008 11:01:31 -0600 From: "Eric Van Hensbergen" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <5d375e920811110830k1c91a401y5e6f39f1737d4240@mail.gmail.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> <29302f743a99f05c1d9ac196b0245f81@9netics.com> <5d375e920811110830k1c91a401y5e6f39f1737d4240@mail.gmail.com> Subject: Re: [9fans] Do we have a catalog of 9P servers? Topicbox-Message-UUID: 3c14731e-ead4-11e9-9d60-3106f5b1d025 On Tue, Nov 11, 2008 at 10:30 AM, Uriel wrote: >> >> operations like these (symlink, readlink, lock, etc.) that only have >> significance at the extremities should not worry the transit relays. >> that was the reason for Text/Rext proposal. >> >> regardless, interpretation of the ops in a hetergeneous environment >> will be a problem. > > It is not a problem if the ops are Topen/Tread/Twrite (on an > alternative attach), as agreed at the first iwp9, sadly people seems > to forget quite easily, > While pretty on whiteboards, this becomes a bit of bitch in the implementation (of both the client and the server). The reason folks want to use 9P on Linux (and other non-Plan 9 things) is the protocols implementation for both client and server is simple and straightforward. .u failed because implementing the extensions was an ugly hack, and it is my belief/experience (yes, I tried implementing extensions this way) would be a similarly ugly hack that wouldn't be very useful in the end. It was based on my experiences with attempting to code extensions in such a way along with discussions with others that led to the current experiment of architecting the extensions as part of the protocol. Like many things, they are being developed to satisfy requirements of others so its likely that only a subset of the operations (if any) will be useful to native Plan 9 or Inferno. The structure of the extensions is such that they are easily ignored by the clients or servers which do not implement them (which wasn't the case with .u). > > (Wasn't the disaster of adding .u to p9p a clear enough indication of > how hopeless that path is?) > Yes, .u was a disaster which is why the most powerful supercomputer in the world is using it for workload distribution and boot-time. It was a failure, that's why its not being integrated into commercial cluster toolkits. It was a failure, that's why its not the current defacto standard for Linux paravirtualized file systems. It was a failure, that's why there's an RDMA protocol instance developed by third-parties, and that's why its not being looked at being integrated into mainframes and why IBM is not considering funding a development team to support it. Absolute, complete, utter disaster. Completely hopeless. -eric