This series completes the implementation of YNL for wireguard,
as previously announced[1].

This series consist of 5 parts:
1) Patch 01-03 - Misc. changes
2) Patch    04 - Add YNL specification for wireguard
3) Patch 05-07 - Transition to a generated UAPI header
4) Patch    08 - Adds a sample program for the generated C library
5) Patch 09-11 - Transition to generated netlink policy code

The main benefit of having a YNL specification is unlocked after the
first 2 parts, the RFC version seems to already have spawned a new
Rust netlink binding[2] using wireguard as it's main example.

Part 3 and 5 validates that the specification is complete and aligned,
the generated code might have a few warts, but they don't matter too
much, and are mostly a transitional problem[3].

Part 4 is possible after part 2, but is ordered after part 3,
as it needs to duplicate the UAPI header in tools/include.

For the non-generated kernel C code the diff stat looks like this:

$ git diff --stat net-next/main..wg-ynl include/ drivers/ \
	':(exclude)*netlink_gen*'
 drivers/net/wireguard/Makefile  |   1 +
 drivers/net/wireguard/netlink.c |  70 +++---------
 include/uapi/linux/wireguard.h  | 190 ++++++--------------------------
 3 files changed, 47 insertions(+), 214 deletions(-)

[1] [PATCH net 0/4] tools: ynl-gen: misc fixes + wireguard ynl plan
    https://lore.kernel.org/r/20250901145034.525518-1-ast@fiberby.net/

[2] https://github.com/one-d-wide/netlink-bindings/

[3] https://lore.kernel.org/r/20251014123201.6ecfd146@kernel.org/

---
v3:
- Spec: Make flags-mask checks implicit (thanks Jakub).
- Sample: Add header to Makefile.deps, and avoid copy (thanks Jakub).

v2: https://lore.kernel.org/r/20251031160539.1701943-1-ast@fiberby.net/
- Add missing forward declaration

v1: https://lore.kernel.org/r/20251029205123.286115-1-ast@fiberby.net/
- Policy arguement to nla_parse_nested() changed to NULL (thanks Johannes).
- Added attr-cnt-name to the spec, to reduce the diff a bit.
- Refined the doc in the spec a bit.
- Reword commit messages a bit.
- Reordered the patches, and reduced the series from 14 to 11 patches.

RFC: https://lore.kernel.org/r/20250904-wg-ynl-rfc@fiberby.net/

Asbjørn Sloth Tønnesen (11):
  wireguard: netlink: validate nested arrays in policy
  wireguard: netlink: use WG_KEY_LEN in policies
  wireguard: netlink: enable strict genetlink validation
  netlink: specs: add specification for wireguard
  uapi: wireguard: move enum wg_cmd
  uapi: wireguard: move flag enums
  uapi: wireguard: generate header with ynl-gen
  tools: ynl: add sample for wireguard
  wireguard: netlink: convert to split ops
  wireguard: netlink: rename netlink handlers
  wireguard: netlink: generate netlink code

 Documentation/netlink/specs/wireguard.yaml | 301 +++++++++++++++++++++
 MAINTAINERS                                |   2 +
 drivers/net/wireguard/Makefile             |   1 +
 drivers/net/wireguard/netlink.c            |  70 +----
 drivers/net/wireguard/netlink_gen.c        |  77 ++++++
 drivers/net/wireguard/netlink_gen.h        |  29 ++
 include/uapi/linux/wireguard.h             | 190 +++----------
 tools/net/ynl/Makefile.deps                |   2 +
 tools/net/ynl/samples/.gitignore           |   1 +
 tools/net/ynl/samples/wireguard.c          | 104 +++++++
 10 files changed, 563 insertions(+), 214 deletions(-)
 create mode 100644 Documentation/netlink/specs/wireguard.yaml
 create mode 100644 drivers/net/wireguard/netlink_gen.c
 create mode 100644 drivers/net/wireguard/netlink_gen.h
 create mode 100644 tools/net/ynl/samples/wireguard.c

-- 
2.51.0

On Wed,  5 Nov 2025 18:32:09 +0000 Asbjørn Sloth Tønnesen wrote:
> This series completes the implementation of YNL for wireguard,
> as previously announced[1].
> 
> This series consist of 5 parts:
> 1) Patch 01-03 - Misc. changes
> 2) Patch    04 - Add YNL specification for wireguard
> 3) Patch 05-07 - Transition to a generated UAPI header
> 4) Patch    08 - Adds a sample program for the generated C library
> 5) Patch 09-11 - Transition to generated netlink policy code
> 
> The main benefit of having a YNL specification is unlocked after the
> first 2 parts, the RFC version seems to already have spawned a new
> Rust netlink binding[2] using wireguard as it's main example.
> 
> Part 3 and 5 validates that the specification is complete and aligned,
> the generated code might have a few warts, but they don't matter too
> much, and are mostly a transitional problem[3].
> 
> Part 4 is possible after part 2, but is ordered after part 3,
> as it needs to duplicate the UAPI header in tools/include.

These LGTM, now.

Jason what's your feeling here? AFAICT the changes to the wg code
are quite minor now. 

On Mon, Nov 10, 2025 at 06:07:46PM -0800, Jakub Kicinski wrote:
> On Wed,  5 Nov 2025 18:32:09 +0000 Asbjørn Sloth Tønnesen wrote:
> > This series completes the implementation of YNL for wireguard,
> > as previously announced[1].
> > 
> > This series consist of 5 parts:
> > 1) Patch 01-03 - Misc. changes
> > 2) Patch    04 - Add YNL specification for wireguard
> > 3) Patch 05-07 - Transition to a generated UAPI header
> > 4) Patch    08 - Adds a sample program for the generated C library
> > 5) Patch 09-11 - Transition to generated netlink policy code
> > 
> > The main benefit of having a YNL specification is unlocked after the
> > first 2 parts, the RFC version seems to already have spawned a new
> > Rust netlink binding[2] using wireguard as it's main example.
> > 
> > Part 3 and 5 validates that the specification is complete and aligned,
> > the generated code might have a few warts, but they don't matter too
> > much, and are mostly a transitional problem[3].
> > 
> > Part 4 is possible after part 2, but is ordered after part 3,
> > as it needs to duplicate the UAPI header in tools/include.
> 
> These LGTM, now.
> 
> Jason what's your feeling here? AFAICT the changes to the wg code
> are quite minor now. 

Reviewing it this week. Thanks for bumping this in my queue.

Jason

On Wed, 12 Nov 2025 04:59:30 +0100 Jason A. Donenfeld wrote:
> On Mon, Nov 10, 2025 at 06:07:46PM -0800, Jakub Kicinski wrote:
> > On Wed,  5 Nov 2025 18:32:09 +0000 Asbjørn Sloth Tønnesen wrote:  
> > > This series completes the implementation of YNL for wireguard,
> > > as previously announced[1].
> > > 
> > > This series consist of 5 parts:
> > > 1) Patch 01-03 - Misc. changes
> > > 2) Patch    04 - Add YNL specification for wireguard
> > > 3) Patch 05-07 - Transition to a generated UAPI header
> > > 4) Patch    08 - Adds a sample program for the generated C library
> > > 5) Patch 09-11 - Transition to generated netlink policy code
> > > 
> > > The main benefit of having a YNL specification is unlocked after the
> > > first 2 parts, the RFC version seems to already have spawned a new
> > > Rust netlink binding[2] using wireguard as it's main example.
> > > 
> > > Part 3 and 5 validates that the specification is complete and aligned,
> > > the generated code might have a few warts, but they don't matter too
> > > much, and are mostly a transitional problem[3].
> > > 
> > > Part 4 is possible after part 2, but is ordered after part 3,
> > > as it needs to duplicate the UAPI header in tools/include.  
> > 
> > These LGTM, now.
> > 
> > Jason what's your feeling here? AFAICT the changes to the wg code
> > are quite minor now.   
> 
> Reviewing it this week. Thanks for bumping this in my queue.

Sadness. We wait a week and no review materializes. I think the patches
are fine so I'll apply them shortly. The expected patch review SLA for
netdev sub-maintainers is 24h (excluding weekends and holidays)
https://docs.kernel.org/next/maintainer/feature-and-driver-maintainers.html

On Mon, Nov 17, 2025 at 04:14:39PM -0800, Jakub Kicinski wrote:
> On Wed, 12 Nov 2025 04:59:30 +0100 Jason A. Donenfeld wrote:
> > On Mon, Nov 10, 2025 at 06:07:46PM -0800, Jakub Kicinski wrote:
> > > On Wed,  5 Nov 2025 18:32:09 +0000 Asbjørn Sloth Tønnesen wrote:  
> > > > This series completes the implementation of YNL for wireguard,
> > > > as previously announced[1].
> > > > 
> > > > This series consist of 5 parts:
> > > > 1) Patch 01-03 - Misc. changes
> > > > 2) Patch    04 - Add YNL specification for wireguard
> > > > 3) Patch 05-07 - Transition to a generated UAPI header
> > > > 4) Patch    08 - Adds a sample program for the generated C library
> > > > 5) Patch 09-11 - Transition to generated netlink policy code
> > > > 
> > > > The main benefit of having a YNL specification is unlocked after the
> > > > first 2 parts, the RFC version seems to already have spawned a new
> > > > Rust netlink binding[2] using wireguard as it's main example.
> > > > 
> > > > Part 3 and 5 validates that the specification is complete and aligned,
> > > > the generated code might have a few warts, but they don't matter too
> > > > much, and are mostly a transitional problem[3].
> > > > 
> > > > Part 4 is possible after part 2, but is ordered after part 3,
> > > > as it needs to duplicate the UAPI header in tools/include.  
> > > 
> > > These LGTM, now.
> > > 
> > > Jason what's your feeling here? AFAICT the changes to the wg code
> > > are quite minor now.   
> > 
> > Reviewing it this week. Thanks for bumping this in my queue.
> 
> Sadness. We wait a week and no review materializes. I think the patches
> are fine so I'll apply them shortly. The expected patch review SLA for
> netdev sub-maintainers is 24h (excluding weekends and holidays)
> https://docs.kernel.org/next/maintainer/feature-and-driver-maintainers.html

Sadness indeed. I've had some urgent matters come up, but this is now
top of the stack, and I've given it a quick preliminary pass. I'd
planned to take this through my wg tree.

Jason

On Tue, 18 Nov 2025 01:43:37 +0100 Jason A. Donenfeld wrote:
> On Mon, Nov 17, 2025 at 04:14:39PM -0800, Jakub Kicinski wrote:
> > On Wed, 12 Nov 2025 04:59:30 +0100 Jason A. Donenfeld wrote:  
> > > Reviewing it this week. Thanks for bumping this in my queue.  
> > 
> > Sadness. We wait a week and no review materializes. I think the patches
> > are fine so I'll apply them shortly. The expected patch review SLA for
> > netdev sub-maintainers is 24h (excluding weekends and holidays)
> > https://docs.kernel.org/next/maintainer/feature-and-driver-maintainers.html  
> 
> Sadness indeed. I've had some urgent matters come up, but this is now
> top of the stack, and I've given it a quick preliminary pass. I'd
> planned to take this through my wg tree.

Alright, I haven't pushed out yet, so let me drop these.
Looking forward to seeing them in a PR..