[9fans] Re: 9p question

[forsyth@caldo.demon.co.uk forsyth@caldo.demon.co.uk]

>>>>>I definitely can not understand why openness is persistent property in the
>>>>>sense that when I clone the open fid the copy happens to be open too.
>>>
>>>clone(5) notes that ``The fid [to be cloned]... must not have been
>>>opened for I/O by an open or create message''.

>>  Well, I certainly can read man page. I ask why there is such limitation,
>>not where and how it is described. Sorry, but I would like to discuss bare
>>9P ( see my previous letter ).

you asked why openness is persistent across clone, and i simply observed that it is not persistent and cannot be,
because clone is expressly prohibited on an already open fid.  it therefore isn't true
that when you `clone the open fid the copy happens to be open too'.

it seems you were really asking: why can't i clone an open fid?
here is my view (not having actually designed the thing).

the operation of Topen, in some file servers, leads to the creation of some server-side
state (eg, the state implied by a file descriptor opened in an underlying operating system,
in the case of u9fs, or as another example, the state created for an open directory to
permit reading it), and that state might not be easily cloned, or not able to be cloned at all
(what does it mean to `clone' a file descriptor's state in unix or a file handle's state in Nt?).
by contrast, the current Tclone clones state that the server can control
and understand completely (eg, local data structures).
it's hard enough trying to implement some of the operations as it is!

the decomposition of function within 9p (or styx) reduces the scope for unexpected interactions
and simplifies the semantics of the protocol's operations, which in turn, can potentially
simplify the implementation of both client and server.  larger actions are composed
of sequences of small, reasonably straightforward primitives.   having implemented
NFS clients and servers, i quickly came to appreciate the difference!