[9fans] Re: 9p question

[Roman Shaposhnick vugluskr@unicorn.math.spbu.ru]

On Thu, 9 Mar 2000 14:08:23 GMT, rob pike wrote:
>> The real reason for the "lengthy" conversation is the Tclone/Twalk
>> part.  That is part of the price that is paid to remove the '/' as a
>> directory separator
>
>No. The real reason is that after each walk the client must check whether
>the point-so-far is in the mount table.  That's why it's done a path
>element at a time, and why it's so slow.  Other designs have been
>proposed that would allow a walk message to contain multiple
>elements (requiring the server to parse and understand '/'),

 I think this would be a very bad thing. From my point of view the main
strength of 9P is the fact that it allows one to manipulate a hierarchy
without bothering how names of the members are encoded. That's like you
have a partial ordered set and define elements via their relationship
between each other. I think this gives a maximum level of freedom in
how one would define a namespace.

>but it's such a pain to change the protocol.

  Oh, yes!

>Seeking on a directory is forbidden because it's hard enough to
>implement reading a union directory without seek.

  What do you mean by "Seeking on a directory" ? As stated in
manual ( read(5) ) "The read request message must have offset and count zero
modulo DIRLEN.". That's the only restriction. Also I see no restrictions
of reading from arbitrary offset in u9fs sources.

>The internal
>structure that must be maintained in the kernel was deemed too
>hard to maintain other than by sequential access, so we made
>seeking on a directory illegal.

 Hmm, I feel I should try to talk with real 9P servers instead of
u9fs.

>It didn't seem worth the implementation
>overhad.  I still feel that way.
>
>>There are a lot of strange things like:
>>     delim $$ define lbr ' roman "{" ' define rbr ' roman "}" '
>>or
>>     $CH sub c$
>>which should be "CH <sub>c</sub>",  I guess.
>
>Would you have noticed this if it didn't contain your name?

  With first capital letter ? No. :)

Thanks,
Roman.