From: mycroftiv@sphericalharmony.com
To: 9fans@9fans.net
Subject: Re: [9fans] the import/exportfs protocol and a proposed import -z flag
Date: Thu, 28 Feb 2013 01:38:54 +0000 [thread overview]
Message-ID: <de61d0740ca4c878da14beded409615e@sphericalharmony.com> (raw)
Charles Forsyth <charles.forsyth@gmail.com> wrote:
> As you'll have noticed, it isn't a great protocol as it stands. I don't
> think your option makes it worse.
Thanks for your perspective. I'm glad that my long-winded explanation
didn't obscure the basic logic too much. It makes sense for import to
be able to dial and attach to an exportfs -a -r listener, and right
now it can't. You mentioned someone was already carrying an
equivalent patch with the -m flag, and another user I spoke with
mentioned they had written their own exportfs server which addressed
this on the exportfs end. Since a few different users have run into
this and wanted to use the "authentication, no tree request" protocol
variant, it would be good I think if all users could connect to that
type of server using a standardized method. If the -m flag already
has some existing users, it might be a better choice than -z for this
option.
> Note that in your example
> import -z tcp!server!9876 somefiles /n/authedimport
> with the existing import you don't need to specify the (now unused)
> somefiles. If I write {import system /net} it sends "/net" as the tree by
> default.
> I think all you'd need to do to make the option tidier is to reject the
> case argc == 3 in the relevant switch if the option is set. Then you could
> write
> (changing the option letter):
> import -m tcp!server!9876 /n/authedimport
> which reads as import by mounting the 9P service on the given connection on
> the given mount point. It's otherwise a little strange to have an
> argument (your "somefiles") that's completely ignored.
I totally agree. In fact I was unclear about this. The way I wrote
it made it seem as if sending the unused parameter was mandatory - but
in fact, import already has this logic:
switch(argc) {
case 2:
mntpt = argv[1];
break;
case 3:
mntpt = argv[2];
So it is already the case that
import -m tcp!server!9876 /n/authedimport
would do the mount at the specified point. I wrote out the version
with the unnecessary parameter to try to clarify what what -z was
doing, but in practice you just write it exactly as you described.
Maybe the argc==3 case should be rejected just as a reminder to the
user that the tree request will not be sent.
Ben Kidwell
-mycroftiv
next reply other threads:[~2013-02-28 1:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-28 1:38 mycroftiv [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-02-27 8:24 mycroftiv
2013-02-27 13:25 ` Charles Forsyth
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=de61d0740ca4c878da14beded409615e@sphericalharmony.com \
--to=mycroftiv@sphericalharmony.com \
--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).