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@xxxxxxxxxx> > Signed-off-by: Lorenzo Bianconi <lorenzo@xxxxxxxxxx> > --- > 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. > 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. > + > +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? > + - > + 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. > + 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 > + 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? > + > +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
