[9fans] the import/exportfs protocol and a proposed import -z flag
Hello. I am writing to 9fans to solicit discussion (and hopefully consensus) about a proposed patch to import(4) to match the options that currently exist in exportfs(4). I have submitted a patch(1) to sources to be found in sources/patch/importz. The readme and manpages for that patch also explain this issue but based on my discussions with other users in IRC, I would like to submit the topic for community analysis. I am sorry for any inaccuracies, please correct any mistakes. I appreciate all the discussion I have had with others already. Summary: currently, the exportfs(4) options -a and -r or -S are incompatible when exportfs is being used as a listener. I propose a simple patch to import to allow import to correctly mount exportfs(4) services that are using these flags. A new flag -z tells import to skip the same part of the protocol (tree request) that exportfs skips when using the -r or -S flags. Example: aux/listen1 tcp!*!9876 /bin/exportfs -a -r /usr/me/authedexport Translated to english, this command says: listen on port 9876, authenticate clients, and then serve this directory. This is a sensible usage of exportfs. However, neither current import(4) or srv(4) and mount is able to connect to an exportfs run with these options. It creates a protocol variant which is currently unsupported. The same issue exists if you substitute the -S flag (exportfs of a service mount usually from /srv). The proposed patch allows you to use this command to mount the above export: import -z tcp!server!9876 somefiles /n/authedimport (because the string for the remote tree is not sent to the server under this protocol variant, somefiles can be any random string.) The implementation of the flag is completely trivial, simply wrapping the tree request code in an if block. It changes no existing behavior of either exportfs or import. No new bugs or incompatibilities in existing scripts and configs are created. The purpose is simply to make import conform to the options which already exist in exportfs. I believe that making exportfs and import symmetrical in terms of supported options and modes is fundamentally sound. At the moment, exportfs is happy to listen with -a -r but nothing can mount it. I see this patch as a bugfix for this poor interaction of flags. In discussing this issue and patch with others, several potential issues and objections have been raised. I would like to discuss them to try to clarify possible objections and misunderstandings. A list of objections and responses: 1. This creates additional complexity. I do not believe so. The complexity is created by the already existing flags to exportfs and their interactions. The -z flag to import exists to match the existing behavior of exportfs and allow to use the existing exportfs options to function in combination without producing non-mountable exports, 2. There is no purpose to this, because a standard exportfs -a of the full root allows the client to request whatever subroot it wants, or mount and then mount any /srv it wants. I understand this point, but I think there are several responses. The first is that fixing broken interactions of seemingly sensible flags is a good thing to do no matter what. You can cp a file by cat file newfile but that doesnt mean that a bug in cp isnt worth fixing, just because you can perform the operation another way. The second is that you could make the same argument for an http server: Why does an http server need to be able to serve a specific subdirectory? You can always serve the whole root of the tree and the client can choose to look in the www subdirectory. - in other words, choosing a specific portion of namespace or a specific /srv is a sensible thing to do to restrict access. As a user, saying I only want to export this much is desirable. 3. The -P patternfiles let you control that also. Yes, but the patternfile mechanism is definitely more complex, and when you have a simple flag like -r to select a given root, why impose the necessity of creating a patternfile rather than using the -r flag which already exists? To some extent this argument and the previous are more arguments about the design of exportfs. My belief is that whatever exportfs does, import needs to support. There are many possible ways to have the protocols work - but I am proposing a simple change to fix a currently existing issue, the question of whether or not the -r or -S flags to exportfs are superfluous is a design issue. Those flags exist, and I believe it makes sense for import(4) to support the same behavior those flags create. Also, my fundamental concern is making exportfs -a -S mountable by something, somehow - the exact mechanism isnt the most important thing. I believe a tiny patch to import makes the most sense in terms of minimalism and simplicity, but you could deal with this issue in many ways - make exportfs and import smarter about tree negotiation, let
[9fans] the import/exportfs protocol - fmt repost
I apologize for the resend. I pasted text written in acme without |fmt first. I'm blushing. Hello. I am writing to 9fans to solicit discussion (and hopefully consensus) about a proposed patch to import(4) to match the options that currently exist in exportfs(4). I have submitted a patch(1) to sources to be found in sources/patch/importz. The readme and manpages for that patch also explain this issue but based on my discussions with other users in IRC, I would like to submit the topic for community analysis. I am sorry for any inaccuracies, please correct any mistakes. I appreciate all the discussion I have had with others already. Summary: currently, the exportfs(4) options -a and -r or -S are incompatible when exportfs is being used as a listener. I propose a simple patch to import to allow import to correctly mount exportfs(4) services that are using these flags. A new flag -z tells import to skip the same part of the protocol (tree request) that exportfs skips when using the -r or -S flags. Example: aux/listen1 tcp!*!9876 /bin/exportfs -a -r /usr/me/authedexport Translated to english, this command says: listen on port 9876, authenticate clients, and then serve this directory. This is a sensible usage of exportfs. However, neither current import(4) or srv(4) and mount is able to connect to an exportfs run with these options. It creates a protocol variant which is currently unsupported. The same issue exists if you substitute the -S flag (exportfs of a service mount usually from /srv). The proposed patch allows you to use this command to mount the above export: import -z tcp!server!9876 somefiles /n/authedimport (because the string for the remote tree is not sent to the server under this protocol variant, somefiles can be any random string.) The implementation of the flag is completely trivial, simply wrapping the tree request code in an if block. It changes no existing behavior of either exportfs or import. No new bugs or incompatibilities in existing scripts and configs are created. The purpose is simply to make import conform to the options which already exist in exportfs. I believe that making exportfs and import symmetrical in terms of supported options and modes is fundamentally sound. At the moment, exportfs is happy to listen with -a -r but nothing can mount it. I see this patch as a bugfix for this poor interaction of flags. In discussing this issue and patch with others, several potential issues and objections have been raised. I would like to discuss them to try to clarify possible objections and misunderstandings. A list of objections and responses: 1. This creates additional complexity. I do not believe so. The complexity is created by the already existing flags to exportfs and their interactions. The -z flag to import exists to match the existing behavior of exportfs and allow to use the existing exportfs options to function in combination without producing non-mountable exports, 2. There is no purpose to this, because a standard exportfs -a of the full root allows the client to request whatever subroot it wants, or mount and then mount any /srv it wants. I understand this point, but I think there are several responses. The first is that fixing broken interactions of seemingly sensible flags is a good thing to do no matter what. You can cp a file by cat file newfile but that doesnt mean that a bug in cp isnt worth fixing, just because you can perform the operation another way. The second is that you could make the same argument for an http server: Why does an http server need to be able to serve a specific subdirectory? You can always serve the whole root of the tree and the client can choose to look in the www subdirectory. - in other words, choosing a specific portion of namespace or a specific /srv is a sensible thing to do to restrict access. As a user, saying I only want to export this much is desirable. 3. The -P patternfiles let you control that also. Yes, but the patternfile mechanism is definitely more complex, and when you have a simple flag like -r to select a given root, why impose the necessity of creating a patternfile rather than using the -r flag which already exists? To some extent this argument and the previous are more arguments about the design of exportfs. My belief is that whatever exportfs does, import needs to support. There are many possible ways to have the protocols work - but I am proposing a simple change to fix a currently existing issue, the question of whether or not the -r or -S flags to exportfs are superfluous is a design issue. Those flags exist, and I believe it makes sense for import(4) to support the same behavior those flags create. Also, my fundamental concern is making exportfs -a -S mountable by something, somehow - the exact mechanism isnt the most important thing. I believe a tiny patch to import makes the most sense in terms of minimalism and simplicity, but you could deal with this issue in many
Re: [9fans] the import/exportfs protocol and a proposed import -z flag
On 27 February 2013 08:24, mycrof...@sphericalharmony.com wrote:
I hope this post leads to constructive discussion of the import/exportfs
protocol.
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 the detailed discussion. I think at least one existing system
already does what you say, using the -m option ([just] mount, skipping the
tree spec),
and if you were to use that in a patch to sources, then eventually that
private change could be eliminated.
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.
As you say, this could also reasonably be an option to srv to authenticate
its connection to a remote exportfs, but the fewer commands that know
this particular protocol, the better, and both import and exportfs already
do that.
Re: [9fans] rc script question
i assumed you wanted a b c as command line arguments in the second case,
not echoed in.
in the first case, you indexed a variable. in the second case, you indexed
nothing.
% rc -c 'echo @ $*(2-) @' a b c
@ b c @
On 27 February 2013 15:41, Steve Simon st...@quintile.net wrote:
Hi,
rc is not working how I expect it to.
This works fine
echo a b c | rc -c 'a=`{read}; echo @ $a(2-) @'
@ b c @
This i did not expect
echo a b c | rc -c 'echo @ $(2-) @'
@ @
Perhaps I need some expectation managment?
-Steve
Re: [9fans] new fork?
On Wed, Feb 27, 2013 at 10:36:14PM +0100, hiro wrote: http://plan10.tumblr.com/ I think this project was renamed 'plan9port'
Re: [9fans] new fork?
I'd have called it Plan A. On Wed, Feb 27, 2013 at 1:36 PM, hiro 23h...@gmail.com wrote: http://plan10.tumblr.com/
Re: [9fans] new fork?
On Wed, Feb 27, 2013 at 1:36 PM, hiro 23h...@gmail.com wrote: http://plan10.tumblr.com/ I'll set up the wiki
Re: [9fans] Intel ICH9R sata controller
On Wed, Feb 27, 2013 at 10:18 PM, David du Colombier 0in...@gmail.com wrote: The Intel ICH9 SATA controller is listed in the wiki, but does anyone know if the Intel ICH9R works? Yes, it is supported in AHCI mode by the sdiahci driver. Great! Thanks q
Re: [9fans] new fork?
There is/was a Plan B. Some of the ideas went into Octopus I think... On Wed, Feb 27, 2013 at 1:45 PM, Devon H. O'Dell devon.od...@gmail.comwrote: 2013/2/27 David Leimbach leim...@gmail.com: I'd have called it Plan A. [Insert horrific Plan B joke here.] On Wed, Feb 27, 2013 at 1:36 PM, hiro 23h...@gmail.com wrote: http://plan10.tumblr.com/
Re: [9fans] new fork?
yes, octopus was a better plan. both should be still avail from our web site. On Feb 27, 2013, at 11:39 PM, David Leimbach leim...@gmail.com wrote: There is/was a Plan B. Some of the ideas went into Octopus I think... On Wed, Feb 27, 2013 at 1:45 PM, Devon H. O'Dell devon.od...@gmail.com wrote: 2013/2/27 David Leimbach leim...@gmail.com: I'd have called it Plan A. [Insert horrific Plan B joke here.] On Wed, Feb 27, 2013 at 1:36 PM, hiro 23h...@gmail.com wrote: http://plan10.tumblr.com/
Re: [9fans] new fork?
Do you guys still use it at lsub? On Feb 27, 2013, at 17:54, Francisco J Ballesteros n...@lsub.org wrote: yes, octopus was a better plan. both should be still avail from our web site. On Feb 27, 2013, at 11:39 PM, David Leimbach leim...@gmail.com wrote: There is/was a Plan B. Some of the ideas went into Octopus I think... On Wed, Feb 27, 2013 at 1:45 PM, Devon H. O'Dell devon.od...@gmail.com wrote: 2013/2/27 David Leimbach leim...@gmail.com: I'd have called it Plan A. [Insert horrific Plan B joke here.] On Wed, Feb 27, 2013 at 1:36 PM, hiro 23h...@gmail.com wrote: http://plan10.tumblr.com/
Re: [9fans] new fork?
until a few weeks ago. it has been retired now. we are working on the next one, but it will take time. On Feb 28, 2013, at 12:05 AM, Matthew Veety mve...@gmail.com wrote: Do you guys still use it at lsub? On Feb 27, 2013, at 17:54, Francisco J Ballesteros n...@lsub.org wrote: yes, octopus was a better plan. both should be still avail from our web site. On Feb 27, 2013, at 11:39 PM, David Leimbach leim...@gmail.com wrote: There is/was a Plan B. Some of the ideas went into Octopus I think... On Wed, Feb 27, 2013 at 1:45 PM, Devon H. O'Dell devon.od...@gmail.com wrote: 2013/2/27 David Leimbach leim...@gmail.com: I'd have called it Plan A. [Insert horrific Plan B joke here.] On Wed, Feb 27, 2013 at 1:36 PM, hiro 23h...@gmail.com wrote: http://plan10.tumblr.com/
Re: [9fans] the import/exportfs protocol and a proposed import -z flag
Charles Forsyth charles.fors...@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
[9fans] Bug in print(2) g verb
I already sent this mail, but it seems that 9fans didn't receive it. The g verb in print(2) does not work properly. The precision flag (%.ng) is supposed to print n significant figures, but it prints n+1 significant figures. This change fixes this behaviour. diff -r d6b623d4cac0 sys/src/libc/fmt/fltfmt.c --- a/sys/src/libc/fmt/fltfmt.c Sat Feb 23 14:05:51 2013 +0100 +++ b/sys/src/libc/fmt/fltfmt.c Wed Feb 27 15:59:34 2013 -0500 @@ -187,6 +187,8 @@ * c3 digits of trailing '0' * c4 digits after '.' */ + if(chr == 'g') /* Significant figures. */ + prec--; c1 = 0; c2 = prec + 1; c3 = 0;
