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



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