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