On 20 January 2014 06:49, Amol Dixit <amold@vmware.com> wrote:

> I


see intro(5): "All requests on a connection share the same fid space"

If several clients share one connection, as intro(5) says:
"the agent managing the sharing must arrange that no two clients choose the
same fid".
That happens for instance with many cpu server processes sharing one 9p
connection to the file server.
That won't apply in your case, unless 9pfuse doesn't distinguish the
different connections at the server.

It's worth (re)reading the description of the protocol in section 5 of the
manual to have a good grasp of
the details, even when they are encapsulated by a library such as lib9p.

"Basically the server should create new internal fids with ClientID+FID to
point to the *same* file  ...".

You don't see that in (say) ramfs, because it has a single connection (the
/srv file), and the kernel correctly manages
the fid space for all client processes. Most 9p services are implemented
that way.

The few existing servers that manage distinct connections (eg, network
connections),
have per-connection state, and put the fid -> file map in that state.
(There isn't any need
to have an extra level of "internal fids", just keep a separate map per
connection.)
In fossil, for instance:

struct Con {
    ...
Fid* fidhash[NFidHash];   /* per-connection Fid map */

struct Fid {
    ...
u32int fidno;      /* actual 32-bit fid number chosen by client */

        Con* con;                /* the Fid belongs to one connection */

File* file;                 /* the Fid points to a File */