On Tue, Nov 11, 2008 at 10:30 AM, Uriel <[EMAIL PROTECTED]> 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

Reply via email to