From: pouya+lists.9fans@nohup.io
To: 9fans@9fans.net
Subject: [9fans] 9p(2) and walk1
Date: Mon, 15 Feb 2021 17:59:33 +0000 [thread overview]
Message-ID: <25c14ae7d3170c12da15b2a1f47fd646@nohup.io> (raw)
9p(2) says the following about
char* (*walk1)(Fid *fid, char *name, Qid *qid);
| Because implementing the full walk message is intricate and prone to
| error, the helper routine walkandclone will handle the request given
| pointers to two functions walk1 and (optionally) clone. [...] Walk1
| should walk fid to name, initializing fid->qid to the new path's
| qid.Both should return nil on success or an error message on error.
And later:
| If the client provides functions srv->walk1 and (optionally)
| srv->clone, the 9P service loop will call walkandclone with these
| functions to handle the request. Unlike the walk1 above, srv->walk1
| must fill in both fid->qid and *qid with the new qid on a successful
| walk.
I think the distinction being made is that if walk1 is populated in a
struct served by srv(2) it needs to set *qid, but not if it's used
instead to construct a walk function explicitly using walkandclone. A
quick look at the source code of lib9p seems to confirm this.
I looked at the implementation of nntpfs(4) and webfs(4), which both
set walk1. The former sets both fid->qid and *qid and the latter only
*qid, which seems it could be ok from a quick look at the source of
lib9p, but goes against the above instructions AFAICS.
Are these subtle differences (the two in the man page and the third in
code) intentional? It's my first time implementing a 9P file system
so apologies if I'm missing something basic.
Thanks,
Pouya
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb39d71a5497bba2d-M226ea8444212b13fc9a35ab2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
next reply other threads:[~2021-02-15 17:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-15 17:59 pouya+lists.9fans [this message]
2021-02-15 21:35 ` [9fans] " Anthony Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25c14ae7d3170c12da15b2a1f47fd646@nohup.io \
--to=pouya+lists.9fans@nohup.io \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).