9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
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

             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).