From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: NeilBrown <neilb@suse.de>, Lorenzo Bianconi <lorenzo@kernel.org>,
linux-nfs@vger.kernel.org, lorenzo.bianconi@redhat.com
Subject: Re: [PATCH] NFSD: add version field to nfsd_rpc_status_show handler
Date: Tue, 08 Aug 2023 10:20:44 -0400 [thread overview]
Message-ID: <ed02b06f96eeeca4d499583f2bdf31a433921aa1.camel@kernel.org> (raw)
In-Reply-To: <ZNJLQIxweTaEsu16@tissot.1015granger.net>
On Tue, 2023-08-08 at 10:03 -0400, Chuck Lever wrote:
> On Tue, Aug 08, 2023 at 09:48:42AM -0400, Jeff Layton wrote:
> > On Tue, 2023-08-08 at 09:24 -0400, Chuck Lever wrote:
> > > On Tue, Aug 08, 2023 at 09:33:23PM +1000, NeilBrown wrote:
> > > > On Tue, 08 Aug 2023, Lorenzo Bianconi wrote:
> > > > > Introduce version field to nfsd_rpc_status handler in order to help
> > > > > the user to maintain backward compatibility.
> > > >
> > > > I wonder if this really helps. What do I do if I see a version that I
> > > > don't understand? Ignore the whole file? That doesn't make for a good
> > > > user experience.
> > >
> > > There is no UX consideration here. A user browsing the file directly
> > > will not care about the version.
> > >
> > > This file is intended to be parsable by scripts and they have to
> > > keep up with the occasional changes in format. Scripts can handle an
> > > unrecogized version however they like.
> > >
> > > This is what we typically get with a made-up format that isn't .ini
> > > or JSON or XML. The file format isn't self-documenting. The final
> > > field on each row is a variable number of tokens, so it will be
> > > nearly impossible to simply add another field without breaking
> > > something.
> > >
> >
> > It shouldn't be a variable number of tokens per line.
>
> That's how NFSv4 COMPOUND operations are displayed. For example:
>
> 0x5d58666f 0x000000d1 0x000186a3 NFSv4 COMPOUND 0000062034739371 192.168.103.67 0 192.168.103.56 20049 OP_SEQUENCE OP_PUTFH OP_READ
>
> The list of operations in the displayed compound are currently
> blank-separated tokens at the end of each row.
>
Oh! That's a bug in missed in my latest review then. The operations
field was delimited by ':' chars at one point. Lorenzo, did you mean to
change that?
IMO, the list of operations should be one field, separated by a distinct
delimiter (like ':').
>
> > If there is, then that's a bug, IMO. We do want it to be simple to
> > just add a new field, published version info notwithstanding.
>
> They could be wrapped in curly braces, or separated by commas, to
> make them all one token.
>
> I haven't looked at NFSv3 output yet, but I expect those extra
> tokens won't even be there in that case.
>
That's probably another bug. Anything not a v4 COMPOUND should have
something as a placeholder. It could just be a single '-' character.
> JSON, yaml, or xml would all address the extensibility problem, just
> as an alternative thought.
>
It would probably be fairly simple to output well-formed yaml instead.
JSON and XML are a bit more of a pain.
For now, we can change the output. We do need to have this settled
before this goes to Linus' tree though.
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2023-08-08 18:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-08 8:21 [PATCH] NFSD: add version field to nfsd_rpc_status_show handler Lorenzo Bianconi
2023-08-08 11:33 ` NeilBrown
2023-08-08 13:24 ` Chuck Lever
2023-08-08 13:48 ` Jeff Layton
2023-08-08 14:03 ` Chuck Lever
2023-08-08 14:20 ` Jeff Layton [this message]
2023-08-08 15:18 ` Chuck Lever
2023-08-08 21:45 ` NeilBrown
2023-08-09 1:04 ` Chuck Lever
2023-08-09 1:29 ` NeilBrown
2023-08-08 17:56 ` Chuck Lever
2023-08-09 7:49 ` Lorenzo Bianconi
2023-08-09 12:53 ` Chuck Lever
2023-08-08 21:32 ` NeilBrown
2023-08-08 11:41 ` Jeff Layton
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=ed02b06f96eeeca4d499583f2bdf31a433921aa1.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=lorenzo.bianconi@redhat.com \
--cc=lorenzo@kernel.org \
--cc=neilb@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.