From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Lorenzo Bianconi <lorenzo@kernel.org>,
linux-nfs@vger.kernel.org, jlayton@kernel.org, neilb@suse.de,
netdev@vger.kernel.org, kuba@kernel.org
Subject: Re: [PATCH v8 1/3] Documentation: netlink: add a YAML spec for nfsd_server
Date: Thu, 14 Sep 2023 12:46:56 +0200 [thread overview]
Message-ID: <ZQLkoHcEddFGpmeN@lore-desk> (raw)
In-Reply-To: <ZP9X/f43T4FwhoPH@tissot.1015granger.net>
[-- Attachment #1: Type: text/plain, Size: 4844 bytes --]
> On Mon, Sep 11, 2023 at 02:49:44PM +0200, Lorenzo Bianconi wrote:
> > Introduce nfsd_server.yaml specs to generate uAPI and netlink
> > code for nfsd server.
> > Add rpc-status specs to define message reported by the nfsd server
> > dumping the pending RPC requests.
> >
> > Tested-by: Jeff Layton <jlayton@kernel.org>
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > ---
> > Documentation/netlink/specs/nfsd_server.yaml | 97 ++++++++++++++++++++
> > 1 file changed, 97 insertions(+)
> > create mode 100644 Documentation/netlink/specs/nfsd_server.yaml
>
> I've had a look... the series is simple and short. Thanks!
>
> My only quibbles right now are cosmetic and naming-related, all
> of which can be addressed when I apply these. So I'm going to
> wait for other review comments to see if we need another version
> or whether I can apply v8 with by-hand clean-ups.
>
> Comments below are what I might change when applying this one.
> This is not (yet) a request for a new version.
Hi Chuck,
thx for the review. Please let me know if I need to post a v9.
>
>
> > diff --git a/Documentation/netlink/specs/nfsd_server.yaml b/Documentation/netlink/specs/nfsd_server.yaml
> > new file mode 100644
> > index 000000000000..e681b493847b
> > --- /dev/null
> > +++ b/Documentation/netlink/specs/nfsd_server.yaml
> > @@ -0,0 +1,97 @@
> > +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
> > +
> > +name: nfsd_server
>
> IMHO "nfsd_server" is redundant. "nfsd" should work.
ack, fine
>
>
> > +
> > +doc:
> > + nfsd server configuration over generic netlink.
> > +
> > +attribute-sets:
> > + -
> > + name: rpc-status-comp-op-attr
> > + enum-name: nfsd-rpc-status-comp-attr
> > + name-prefix: nfsd-attr-rpc-status-comp-
> > + attributes:
> > + -
> > + name: unspec
> > + type: unused
> > + value: 0
>
> I don't recall whether a zero-value definition is explicitly
> necessary. Maybe "value-start: 1" would work rather than
> these three lines? Why is zero a special attribute value?
I do not think it is mandatory, I added them just to be aligned with other
netlink definitions, but we do not use them.
>
>
> > + -
> > + name: op
> > + type: u32
> > + -
> > + name: rpc-status-attr
> > + enum-name: nfsd-rpc-status-attr
> > + name-prefix: nfsd-attr-rpc-status-
>
> Specifying all three of these name settings seems a bit
> cluttered.
ack, I would say we can get rid of enum-name, agree?
>
>
> > + attributes:
> > + -
> > + name: unspec
> > + type: unused
> > + value: 0
> > + -
> > + name: xid
> > + type: u32
> > + byte-order: big-endian
> > + -
> > + name: flags
> > + type: u32
> > + -
> > + name: prog
> > + type: u32
> > + -
> > + name: version
> > + type: u8
> > + -
> > + name: proc
> > + type: u32
> > + -
> > + name: service_time
> > + type: s64
> > + -
> > + name: pad
> > + type: pad
> > + -
> > + name: saddr4
> > + type: u32
> > + byte-order: big-endian
> > + display-hint: ipv4
> > + -
> > + name: daddr4
> > + type: u32
> > + byte-order: big-endian
> > + display-hint: ipv4
> > + -
> > + name: saddr6
> > + type: binary
> > + display-hint: ipv6
> > + -
> > + name: daddr6
> > + type: binary
> > + display-hint: ipv6
> > + -
> > + name: sport
> > + type: u16
> > + byte-order: big-endian
> > + -
> > + name: dport
> > + type: u16
> > + byte-order: big-endian
> > + -
> > + name: compond-op
>
> s/compond-op/compound-op
ack
>
> > + type: array-nest
> > + nested-attributes: rpc-status-comp-op-attr
>
> So, this is supposed to be a counted array of op numbers? Is there
> an existing type that could be used for this instead?
I think the attribute-sets available types are defined here:
https://github.com/torvalds/linux/blob/master/Documentation/netlink/genetlink-c.yaml#L151
Regards,
Lorenzo
>
>
> > +
> > +operations:
> > + enum-name: nfsd-commands
> > + name-prefix: nfsd-cmd-
> > + list:
> > + -
> > + name: unspec
> > + doc: unused
> > + value: 0
> > + -
> > + name: rpc-status-get
> > + doc: dump pending nfsd rpc
> > + attribute-set: rpc-status-attr
> > + dump:
> > + pre: nfsd-server-nl-rpc-status-get-start
> > + post: nfsd-server-nl-rpc-status-get-done
>
> --
> Chuck Lever
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2023-09-14 10:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-11 12:49 [PATCH v8 0/3] add rpc_status netlink support for NFSD Lorenzo Bianconi
2023-09-11 12:49 ` [PATCH v8 1/3] Documentation: netlink: add a YAML spec for nfsd_server Lorenzo Bianconi
2023-09-11 17:20 ` Jeff Layton
2023-09-11 18:10 ` Chuck Lever
2023-09-14 10:46 ` Lorenzo Bianconi [this message]
2023-10-03 17:55 ` Jakub Kicinski
2023-10-03 18:40 ` Chuck Lever III
2023-10-03 19:02 ` Jakub Kicinski
2023-10-03 23:00 ` Chuck Lever III
2023-10-04 0:24 ` Jakub Kicinski
2023-09-11 12:49 ` [PATCH v8 2/3] NFSD: introduce netlink rpc_status stubs Lorenzo Bianconi
2023-09-11 19:35 ` Jeff Layton
2023-09-11 19:55 ` Chuck Lever
2023-09-14 11:20 ` Lorenzo Bianconi
2023-09-12 15:07 ` Simon Horman
2023-09-14 11:25 ` Lorenzo Bianconi
2023-09-11 12:49 ` [PATCH v8 3/3] NFSD: add rpc_status netlink support Lorenzo Bianconi
2023-09-11 19:43 ` Jeff Layton
2023-09-12 15:13 ` Simon Horman
2023-09-14 11:41 ` Lorenzo Bianconi
2023-10-03 18:03 ` Jakub Kicinski
2023-10-04 10:14 ` Lorenzo Bianconi
2023-10-04 13:27 ` Chuck Lever III
2023-10-04 14:04 ` Lorenzo Bianconi
2023-12-11 18:56 ` Jeff Layton
2023-12-12 12:07 ` Jeff Layton
2023-09-15 19:24 ` [PATCH v8 0/3] add rpc_status netlink support for NFSD Chuck Lever
2023-09-15 21:30 ` Lorenzo Bianconi
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=ZQLkoHcEddFGpmeN@lore-desk \
--to=lorenzo.bianconi@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=neilb@suse.de \
--cc=netdev@vger.kernel.org \
/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).