[PATCH net-next v3 00/11] wireguard: netlink: ynl conversion

[PATCH net-next v3 00/11] wireguard: netlink: ynl conversion

[Asbjørn Sloth Tønnesen]

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

[PATCH net-next v3 01/11] wireguard: netlink: validate nested arrays in policy

[Asbjørn Sloth Tønnesen]

Use NLA_POLICY_NESTED_ARRAY() to perform nested array validation
in the policy validation step.

The nested policy was already enforced through nla_parse_nested(),
however extack wasn't passed previously.

Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
---
 drivers/net/wireguard/netlink.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireguard/netlink.c b/drivers/net/wireguard/netlink.c
index 67f962eb8b46..e4416f23d427 100644
--- a/drivers/net/wireguard/netlink.c
+++ b/drivers/net/wireguard/netlink.c
@@ -18,6 +18,8 @@
 #include <crypto/utils.h>
 
 static struct genl_family genl_family;
+static const struct nla_policy peer_policy[WGPEER_A_MAX + 1];
+static const struct nla_policy allowedip_policy[WGALLOWEDIP_A_MAX + 1];
 
 static const struct nla_policy device_policy[WGDEVICE_A_MAX + 1] = {
 	[WGDEVICE_A_IFINDEX]		= { .type = NLA_U32 },
@@ -27,7 +29,7 @@ static const struct nla_policy device_policy[WGDEVICE_A_MAX + 1] = {
 	[WGDEVICE_A_FLAGS]		= NLA_POLICY_MASK(NLA_U32, __WGDEVICE_F_ALL),
 	[WGDEVICE_A_LISTEN_PORT]	= { .type = NLA_U16 },
 	[WGDEVICE_A_FWMARK]		= { .type = NLA_U32 },
-	[WGDEVICE_A_PEERS]		= { .type = NLA_NESTED }
+	[WGDEVICE_A_PEERS]		= NLA_POLICY_NESTED_ARRAY(peer_policy),
 };
 
 static const struct nla_policy peer_policy[WGPEER_A_MAX + 1] = {
@@ -39,7 +41,7 @@ static const struct nla_policy peer_policy[WGPEER_A_MAX + 1] = {
 	[WGPEER_A_LAST_HANDSHAKE_TIME]			= NLA_POLICY_EXACT_LEN(sizeof(struct __kernel_timespec)),
 	[WGPEER_A_RX_BYTES]				= { .type = NLA_U64 },
 	[WGPEER_A_TX_BYTES]				= { .type = NLA_U64 },
-	[WGPEER_A_ALLOWEDIPS]				= { .type = NLA_NESTED },
+	[WGPEER_A_ALLOWEDIPS]				= NLA_POLICY_NESTED_ARRAY(allowedip_policy),
 	[WGPEER_A_PROTOCOL_VERSION]			= { .type = NLA_U32 }
 };
 
@@ -467,7 +469,7 @@ static int set_peer(struct wg_device *wg, struct nlattr **attrs)
 
 		nla_for_each_nested(attr, attrs[WGPEER_A_ALLOWEDIPS], rem) {
 			ret = nla_parse_nested(allowedip, WGALLOWEDIP_A_MAX,
-					       attr, allowedip_policy, NULL);
+					       attr, NULL, NULL);
 			if (ret < 0)
 				goto out;
 			ret = set_allowedip(peer, allowedip);
@@ -593,7 +595,7 @@ static int wg_set_device(struct sk_buff *skb, struct genl_info *info)
 
 		nla_for_each_nested(attr, info->attrs[WGDEVICE_A_PEERS], rem) {
 			ret = nla_parse_nested(peer, WGPEER_A_MAX, attr,
-					       peer_policy, NULL);
+					       NULL, NULL);
 			if (ret < 0)
 				goto out;
 			ret = set_peer(wg, peer);
-- 
2.51.0

[PATCH net-next v3 02/11] wireguard: netlink: use WG_KEY_LEN in policies

[Asbjørn Sloth Tønnesen]

When converting the netlink policies to YNL, then the constants
used in the policy has to be visible to user-space.

As NOISE_*_KEY_LEN isn't visible for userspace, then change the
policy to use WG_KEY_LEN, as is also documented in the UAPI header:

$ grep WG_KEY_LEN include/uapi/linux/wireguard.h
 *    WGDEVICE_A_PRIVATE_KEY: NLA_EXACT_LEN, len WG_KEY_LEN
 *    WGDEVICE_A_PUBLIC_KEY: NLA_EXACT_LEN, len WG_KEY_LEN
 *            WGPEER_A_PUBLIC_KEY: NLA_EXACT_LEN, len WG_KEY_LEN
 *            WGPEER_A_PRESHARED_KEY: NLA_EXACT_LEN, len WG_KEY_LEN
 [...]

Add a couple of BUILD_BUG_ON() to ensure that they stay in sync.

No behavioural changes intended.

Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
---
 drivers/net/wireguard/netlink.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireguard/netlink.c b/drivers/net/wireguard/netlink.c
index e4416f23d427..db57a74d379b 100644
--- a/drivers/net/wireguard/netlink.c
+++ b/drivers/net/wireguard/netlink.c
@@ -24,8 +24,8 @@ static const struct nla_policy allowedip_policy[WGALLOWEDIP_A_MAX + 1];
 static const struct nla_policy device_policy[WGDEVICE_A_MAX + 1] = {
 	[WGDEVICE_A_IFINDEX]		= { .type = NLA_U32 },
 	[WGDEVICE_A_IFNAME]		= { .type = NLA_NUL_STRING, .len = IFNAMSIZ - 1 },
-	[WGDEVICE_A_PRIVATE_KEY]	= NLA_POLICY_EXACT_LEN(NOISE_PUBLIC_KEY_LEN),
-	[WGDEVICE_A_PUBLIC_KEY]		= NLA_POLICY_EXACT_LEN(NOISE_PUBLIC_KEY_LEN),
+	[WGDEVICE_A_PRIVATE_KEY]	= NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
+	[WGDEVICE_A_PUBLIC_KEY]		= NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
 	[WGDEVICE_A_FLAGS]		= NLA_POLICY_MASK(NLA_U32, __WGDEVICE_F_ALL),
 	[WGDEVICE_A_LISTEN_PORT]	= { .type = NLA_U16 },
 	[WGDEVICE_A_FWMARK]		= { .type = NLA_U32 },
@@ -33,8 +33,8 @@ static const struct nla_policy device_policy[WGDEVICE_A_MAX + 1] = {
 };
 
 static const struct nla_policy peer_policy[WGPEER_A_MAX + 1] = {
-	[WGPEER_A_PUBLIC_KEY]				= NLA_POLICY_EXACT_LEN(NOISE_PUBLIC_KEY_LEN),
-	[WGPEER_A_PRESHARED_KEY]			= NLA_POLICY_EXACT_LEN(NOISE_SYMMETRIC_KEY_LEN),
+	[WGPEER_A_PUBLIC_KEY]				= NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
+	[WGPEER_A_PRESHARED_KEY]			= NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
 	[WGPEER_A_FLAGS]				= NLA_POLICY_MASK(NLA_U32, __WGPEER_F_ALL),
 	[WGPEER_A_ENDPOINT]				= NLA_POLICY_MIN_LEN(sizeof(struct sockaddr)),
 	[WGPEER_A_PERSISTENT_KEEPALIVE_INTERVAL]	= { .type = NLA_U16 },
@@ -644,6 +644,9 @@ static struct genl_family genl_family __ro_after_init = {
 
 int __init wg_genetlink_init(void)
 {
+	BUILD_BUG_ON(WG_KEY_LEN != NOISE_PUBLIC_KEY_LEN);
+	BUILD_BUG_ON(WG_KEY_LEN != NOISE_SYMMETRIC_KEY_LEN);
+
 	return genl_register_family(&genl_family);
 }
 
-- 
2.51.0

[PATCH net-next v3 03/11] wireguard: netlink: enable strict genetlink validation

[Asbjørn Sloth Tønnesen]

Wireguard is a modern enough genetlink family, that it doesn't
need resv_start_op. It already had policies in place when it was
first merged, it has also never used the reserved field, or other
things toggled by resv_start_op.

wireguard-tools have always used zero initialized memory, and
have never touched the reserved field, neither have any other
clients I have checked. Closed-source clients are much more
likely to use the embeddedable library from wireguard-tools,
than a DIY implementation using uninitialized memory.

Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
---
 drivers/net/wireguard/netlink.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireguard/netlink.c b/drivers/net/wireguard/netlink.c
index db57a74d379b..682678d24a9f 100644
--- a/drivers/net/wireguard/netlink.c
+++ b/drivers/net/wireguard/netlink.c
@@ -633,7 +633,6 @@ static const struct genl_ops genl_ops[] = {
 static struct genl_family genl_family __ro_after_init = {
 	.ops = genl_ops,
 	.n_ops = ARRAY_SIZE(genl_ops),
-	.resv_start_op = WG_CMD_SET_DEVICE + 1,
 	.name = WG_GENL_NAME,
 	.version = WG_GENL_VERSION,
 	.maxattr = WGDEVICE_A_MAX,
-- 
2.51.0

Re: [PATCH net-next v3 03/11] wireguard: netlink: enable strict genetlink validation

[Jason A. Donenfeld]

On Wed, Nov 05, 2025 at 06:32:12PM +0000, Asbjørn Sloth Tønnesen wrote:
> Wireguard is a modern enough genetlink family, that it doesn't

WireGuard, capital G.

Re: [PATCH net-next v3 03/11] wireguard: netlink: enable strict genetlink validation

[Jason A. Donenfeld]

Hi Asbjørn,

On Wed, Nov 5, 2025 at 7:32 PM Asbjørn Sloth Tønnesen <ast@fiberby.net> wrote:
>  static struct genl_family genl_family __ro_after_init = {
>         .ops = genl_ops,
>         .n_ops = ARRAY_SIZE(genl_ops),
> -       .resv_start_op = WG_CMD_SET_DEVICE + 1,
>         .name = WG_GENL_NAME,
>         .version = WG_GENL_VERSION,
>         .maxattr = WGDEVICE_A_MAX,

This patch is fine and standalone enough, that I merged it into my
wireguard.git devel branch:

https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/wireguard-linux.git/commit/?h=devel&id=fbd8c752a8e3d00341fa7754d6e45e60d6b45490

If you wind up rerolling the rest of these, you can do it against that branch.

Jason

Re: [PATCH net-next v3 03/11] wireguard: netlink: enable strict genetlink validation

[Asbjørn Sloth Tønnesen]

On 11/18/25 5:10 PM, Jason A. Donenfeld wrote:
> On Wed, Nov 5, 2025 at 7:32 PM Asbjørn Sloth Tønnesen <ast@fiberby.net> wrote:
>>   static struct genl_family genl_family __ro_after_init = {
>>          .ops = genl_ops,
>>          .n_ops = ARRAY_SIZE(genl_ops),
>> -       .resv_start_op = WG_CMD_SET_DEVICE + 1,
>>          .name = WG_GENL_NAME,
>>          .version = WG_GENL_VERSION,
>>          .maxattr = WGDEVICE_A_MAX,
> 
> This patch is fine and standalone enough, that I merged it into my
> wireguard.git devel branch:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/wireguard-linux.git/commit/?h=devel&id=fbd8c752a8e3d00341fa7754d6e45e60d6b45490
> 
> If you wind up rerolling the rest of these, you can do it against that branch.

If you update it, so it includes the 2 new net-next commits, then
I can send v4 based on your tree.

- [net-next,1/2] tools: ynl-gen: add function prefix argument
   https://git.kernel.org/netdev/net-next/c/17fa6ee35bd4
- [net-next,2/2] tools: ynl-gen: add regeneration comment
   https://git.kernel.org/netdev/net-next/c/68e83f347266

Thanks.

Re: [PATCH net-next v3 03/11] wireguard: netlink: enable strict genetlink validation

[Jason A. Donenfeld]

On Wed, Nov 26, 2025 at 5:25 PM Asbjørn Sloth Tønnesen <ast@fiberby.net> wrote:
>
> On 11/18/25 5:10 PM, Jason A. Donenfeld wrote:
> > On Wed, Nov 5, 2025 at 7:32 PM Asbjørn Sloth Tønnesen <ast@fiberby.net> wrote:
> >>   static struct genl_family genl_family __ro_after_init = {
> >>          .ops = genl_ops,
> >>          .n_ops = ARRAY_SIZE(genl_ops),
> >> -       .resv_start_op = WG_CMD_SET_DEVICE + 1,
> >>          .name = WG_GENL_NAME,
> >>          .version = WG_GENL_VERSION,
> >>          .maxattr = WGDEVICE_A_MAX,
> >
> > This patch is fine and standalone enough, that I merged it into my
> > wireguard.git devel branch:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/wireguard-linux.git/commit/?h=devel&id=fbd8c752a8e3d00341fa7754d6e45e60d6b45490
> >
> > If you wind up rerolling the rest of these, you can do it against that branch.
>
> If you update it, so it includes the 2 new net-next commits, then
> I can send v4 based on your tree.

Done.

[PATCH net-next v3 04/11] netlink: specs: add specification for wireguard

[Asbjørn Sloth Tønnesen]

This patch adds an near[1] complete YNL specification for wireguard,
documenting the protocol in a machine-readable format, than the
comment in wireguard.h, and eases usage from C and non-C programming
languages alike.

The generated C library will be featured in the next patch, so in
this patch I will use the in-kernel python client for examples.

This makes the documentation in the UAPI header redundant, and
it is therefore removed. The in-line documentation in the spec,
is based on the existing comment in wireguard.h, and once released
then it will be available in the kernel documentation at:
  https://docs.kernel.org/netlink/specs/wireguard.html
  (until then run: make htmldocs)

Generate wireguard.rst from this spec:
$ make -C tools/net/ynl/generated/ wireguard.rst

Query wireguard interface through pyynl:
$ sudo ./tools/net/ynl/pyynl/cli.py --family wireguard \
                                    --dump get-device \
                                    --json '{"ifindex":3}'
[{'fwmark': 0,
  'ifindex': 3,
  'ifname': 'wg-test',
  'listen-port': 54318,
  'peers': [{0: {'allowedips': [{0: {'cidr-mask': 0,
                                     'family': 2,
                                     'ipaddr': '0.0.0.0'}},
                                {0: {'cidr-mask': 0,
                                     'family': 10,
                                     'ipaddr': '::'}}],
                 'endpoint': b'[...]',
                 'last-handshake-time': {'nsec': 42, 'sec': 42},
                 'persistent-keepalive-interval': 42,
                 'preshared-key': '[...]',
                 'protocol-version': 1,
                 'public-key': '[...]',
                 'rx-bytes': 42,
                 'tx-bytes': 42}}],
  'private-key': '[...]',
  'public-key': '[...]'}]

Add another allowed IP prefix:
$ sudo ./tools/net/ynl/pyynl/cli.py --family wireguard \
  --do set-device --json '{"ifindex":3,"peers":[
    {"public-key":"6a df b1 83 a4 ..","allowedips":[
      {"cidr-mask":0,"family":10,"ipaddr":"::"}]}]}'

[1] As can be seen above, the "endpoint" is only decoded as binary data,
    as it can't be described fully in YNL. It's a struct sockaddr_in or
    struct sockaddr_in6 depending on the attribute length.

Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
---
 Documentation/netlink/specs/wireguard.yaml | 301 +++++++++++++++++++++
 MAINTAINERS                                |   1 +
 include/uapi/linux/wireguard.h             | 129 ---------
 3 files changed, 302 insertions(+), 129 deletions(-)
 create mode 100644 Documentation/netlink/specs/wireguard.yaml

diff --git a/Documentation/netlink/specs/wireguard.yaml b/Documentation/netlink/specs/wireguard.yaml
new file mode 100644
index 000000000000..7dcb2dec3d06
--- /dev/null
+++ b/Documentation/netlink/specs/wireguard.yaml
@@ -0,0 +1,301 @@
+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+---
+name: wireguard
+protocol: genetlink-legacy
+
+doc: |
+  **Netlink protocol to control WireGuard network devices.**
+
+  The below enums and macros are for interfacing with WireGuard,
+  using generic netlink, with family ``WG_GENL_NAME`` and version
+  ``WG_GENL_VERSION``. It defines two commands: get and set.
+  Note that while they share many common attributes, these two
+  commands actually accept a slightly different set of inputs and
+  outputs. These differences are noted under the individual attributes.
+c-family-name: wg-genl-name
+c-version-name: wg-genl-version
+max-by-define: true
+
+definitions:
+  -
+    name-prefix: wg-
+    name: key-len
+    type: const
+    value: 32
+  -
+    name: --kernel-timespec
+    type: struct
+    header: linux/time_types.h
+    members:
+      -
+        name: sec
+        type: u64
+        doc: Number of seconds, since UNIX epoch.
+      -
+        name: nsec
+        type: u64
+        doc: Number of nanoseconds, after the second began.
+  -
+    name: wgdevice-flags
+    name-prefix: wgdevice-f-
+    enum-name: wgdevice-flag
+    type: flags
+    entries:
+      - replace-peers
+  -
+    name: wgpeer-flags
+    name-prefix: wgpeer-f-
+    enum-name: wgpeer-flag
+    type: flags
+    entries:
+      - remove-me
+      - replace-allowedips
+      - update-only
+  -
+    name: wgallowedip-flags
+    name-prefix: wgallowedip-f-
+    enum-name: wgallowedip-flag
+    type: flags
+    entries:
+      - remove-me
+
+attribute-sets:
+  -
+    name: wgdevice
+    enum-name: wgdevice-attribute
+    name-prefix: wgdevice-a-
+    attr-cnt-name: --wgdevice-a-last
+    attributes:
+      -
+        name: unspec
+        type: unused
+        value: 0
+      -
+        name: ifindex
+        type: u32
+      -
+        name: ifname
+        type: string
+        checks:
+          max-len: 15
+      -
+        name: private-key
+        type: binary
+        doc: Set to all zeros to remove.
+        display-hint: hex
+        checks:
+          exact-len: wg-key-len
+      -
+        name: public-key
+        type: binary
+        display-hint: hex
+        checks:
+          exact-len: wg-key-len
+      -
+        name: flags
+        type: u32
+        doc: |
+          ``0`` or ``WGDEVICE_F_REPLACE_PEERS`` if all current peers
+          should be removed prior to adding the list below.
+        enum: wgdevice-flags
+      -
+        name: listen-port
+        type: u16
+        doc: Set as ``0`` to choose randomly.
+      -
+        name: fwmark
+        type: u32
+        doc: Set as ``0`` to disable.
+      -
+        name: peers
+        type: indexed-array
+        sub-type: nest
+        nested-attributes: wgpeer
+        doc: The index is set as ``0`` in ``DUMP``, and unused in ``DO``.
+  -
+    name: wgpeer
+    enum-name: wgpeer-attribute
+    name-prefix: wgpeer-a-
+    attr-cnt-name: --wgpeer-a-last
+    attributes:
+      -
+        name: unspec
+        type: unused
+        value: 0
+      -
+        name: public-key
+        type: binary
+        display-hint: hex
+        checks:
+          exact-len: wg-key-len
+      -
+        name: preshared-key
+        type: binary
+        doc: Set as all zeros to remove.
+        display-hint: hex
+        checks:
+          exact-len: wg-key-len
+      -
+        name: flags
+        type: u32
+        doc: |
+          ``0`` and/or ``WGPEER_F_REMOVE_ME`` if the specified peer should not
+          exist at the end of the operation, rather than added/updated
+          and/or ``WGPEER_F_REPLACE_ALLOWEDIPS`` if all current allowed IPs
+          of this peer should be removed prior to adding the list below
+          and/or ``WGPEER_F_UPDATE_ONLY`` if the peer should only be set if
+          it already exists.
+        enum: wgpeer-flags
+      -
+        name: endpoint
+        type: binary
+        doc: struct sockaddr_in or struct sockaddr_in6
+        checks:
+          min-len: 16
+      -
+        name: persistent-keepalive-interval
+        type: u16
+        doc: Set as ``0`` to disable.
+      -
+        name: last-handshake-time
+        type: binary
+        struct: --kernel-timespec
+        checks:
+          exact-len: 16
+      -
+        name: rx-bytes
+        type: u64
+      -
+        name: tx-bytes
+        type: u64
+      -
+        name: allowedips
+        type: indexed-array
+        sub-type: nest
+        nested-attributes: wgallowedip
+        doc: The index is set as ``0`` in ``DUMP``, and unused in ``DO``.
+      -
+        name: protocol-version
+        type: u32
+        doc: |
+          Should not be set or used at all by most users of this API,
+          as the most recent protocol will be used when this is unset.
+          Otherwise, must be set to ``1``.
+  -
+    name: wgallowedip
+    enum-name: wgallowedip-attribute
+    name-prefix: wgallowedip-a-
+    attr-cnt-name: --wgallowedip-a-last
+    attributes:
+      -
+        name: unspec
+        type: unused
+        value: 0
+      -
+        name: family
+        type: u16
+        doc: IP family, either ``AF_INET`` or ``AF_INET6``.
+      -
+        name: ipaddr
+        type: binary
+        doc: Either ``struct in_addr`` or ``struct in6_addr``.
+        display-hint: ipv4-or-v6
+        checks:
+          min-len: 4
+      -
+        name: cidr-mask
+        type: u8
+      -
+        name: flags
+        type: u32
+        doc: |
+          ``WGALLOWEDIP_F_REMOVE_ME`` if the specified IP should be
+          removed; otherwise, this IP will be added if it is not
+          already present.
+        enum: wgallowedip-flags
+
+operations:
+  enum-name: wg-cmd
+  name-prefix: wg-cmd-
+  list:
+    -
+      name: get-device
+      value: 0
+      doc: |
+        Retrieve WireGuard device
+        ~~~~~~~~~~~~~~~~~~~~~~~~~
+
+        The command should be called with one but not both of:
+
+        - ``WGDEVICE_A_IFINDEX``
+        - ``WGDEVICE_A_IFNAME``
+
+        The kernel will then return several messages (``NLM_F_MULTI``).
+        It is possible that all of the allowed IPs of a single peer
+        will not fit within a single netlink message. In that case, the
+        same peer will be written in the following message, except it will
+        only contain ``WGPEER_A_PUBLIC_KEY`` and ``WGPEER_A_ALLOWEDIPS``.
+        This may occur several times in a row for the same peer.
+        It is then up to the receiver to coalesce adjacent peers.
+        Likewise, it is possible that all peers will not fit within a
+        single message.
+        So, subsequent peers will be sent in following messages,
+        except those will only contain ``WGDEVICE_A_IFNAME`` and
+        ``WGDEVICE_A_PEERS``. It is then up to the receiver to coalesce
+        these messages to form the complete list of peers.
+
+        While this command does accept the other ``WGDEVICE_A_*``
+        attributes, for compatibility reasons, but they are ignored
+        by this command, and should not be used in requests.
+
+        Since this is an ``NLA_F_DUMP`` command, the final message will
+        always be ``NLMSG_DONE``, even if an error occurs. However, this
+        ``NLMSG_DONE`` message contains an integer error code. It is
+        either zero or a negative error code corresponding to the errno.
+      attribute-set: wgdevice
+      flags: [uns-admin-perm]
+
+      dump:
+        pre: wireguard-nl-get-device-start
+        post: wireguard-nl-get-device-done
+        # request only uses ifindex | ifname, but keep .maxattr as is
+        request: &all-attrs
+          attributes:
+            - ifindex
+            - ifname
+            - private-key
+            - public-key
+            - flags
+            - listen-port
+            - fwmark
+            - peers
+        reply: *all-attrs
+    -
+      name: set-device
+      value: 1
+      doc: |
+        Set WireGuard device
+        ~~~~~~~~~~~~~~~~~~~~
+
+        This command should be called with a wgdevice set, containing one
+        but not both of ``WGDEVICE_A_IFINDEX`` and ``WGDEVICE_A_IFNAME``.
+
+        It is possible that the amount of configuration data exceeds that
+        of the maximum message length accepted by the kernel.
+        In that case, several messages should be sent one after another,
+        with each successive one filling in information not contained in
+        the prior.
+        Note that if ``WGDEVICE_F_REPLACE_PEERS`` is specified in the first
+        message, it probably should not be specified in fragments that come
+        after, so that the list of peers is only cleared the first time but
+        appended after.
+        Likewise for peers, if ``WGPEER_F_REPLACE_ALLOWEDIPS`` is specified
+        in the first message of a peer, it likely should not be specified
+        in subsequent fragments.
+
+        If an error occurs, ``NLMSG_ERROR`` will reply containing an errno.
+      attribute-set: wgdevice
+      flags: [uns-admin-perm]
+
+      do:
+        request: *all-attrs
diff --git a/MAINTAINERS b/MAINTAINERS
index bdf0a3a0dd36..35cd289899f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27649,6 +27649,7 @@ M:	Jason A. Donenfeld <Jason@zx2c4.com>
 L:	wireguard@lists.zx2c4.com
 L:	netdev@vger.kernel.org
 S:	Maintained
+F:	Documentation/netlink/specs/wireguard.yaml
 F:	drivers/net/wireguard/
 F:	tools/testing/selftests/wireguard/
 
diff --git a/include/uapi/linux/wireguard.h b/include/uapi/linux/wireguard.h
index 8c26391196d5..dee4401e0b5d 100644
--- a/include/uapi/linux/wireguard.h
+++ b/include/uapi/linux/wireguard.h
@@ -1,135 +1,6 @@
 /* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT */
 /*
  * Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
- *
- * Documentation
- * =============
- *
- * The below enums and macros are for interfacing with WireGuard, using generic
- * netlink, with family WG_GENL_NAME and version WG_GENL_VERSION. It defines two
- * methods: get and set. Note that while they share many common attributes,
- * these two functions actually accept a slightly different set of inputs and
- * outputs.
- *
- * WG_CMD_GET_DEVICE
- * -----------------
- *
- * May only be called via NLM_F_REQUEST | NLM_F_DUMP. The command should contain
- * one but not both of:
- *
- *    WGDEVICE_A_IFINDEX: NLA_U32
- *    WGDEVICE_A_IFNAME: NLA_NUL_STRING, maxlen IFNAMSIZ - 1
- *
- * The kernel will then return several messages (NLM_F_MULTI) containing the
- * following tree of nested items:
- *
- *    WGDEVICE_A_IFINDEX: NLA_U32
- *    WGDEVICE_A_IFNAME: NLA_NUL_STRING, maxlen IFNAMSIZ - 1
- *    WGDEVICE_A_PRIVATE_KEY: NLA_EXACT_LEN, len WG_KEY_LEN
- *    WGDEVICE_A_PUBLIC_KEY: NLA_EXACT_LEN, len WG_KEY_LEN
- *    WGDEVICE_A_LISTEN_PORT: NLA_U16
- *    WGDEVICE_A_FWMARK: NLA_U32
- *    WGDEVICE_A_PEERS: NLA_NESTED
- *        0: NLA_NESTED
- *            WGPEER_A_PUBLIC_KEY: NLA_EXACT_LEN, len WG_KEY_LEN
- *            WGPEER_A_PRESHARED_KEY: NLA_EXACT_LEN, len WG_KEY_LEN
- *            WGPEER_A_ENDPOINT: NLA_MIN_LEN(struct sockaddr), struct sockaddr_in or struct sockaddr_in6
- *            WGPEER_A_PERSISTENT_KEEPALIVE_INTERVAL: NLA_U16
- *            WGPEER_A_LAST_HANDSHAKE_TIME: NLA_EXACT_LEN, struct __kernel_timespec
- *            WGPEER_A_RX_BYTES: NLA_U64
- *            WGPEER_A_TX_BYTES: NLA_U64
- *            WGPEER_A_ALLOWEDIPS: NLA_NESTED
- *                0: NLA_NESTED
- *                    WGALLOWEDIP_A_FAMILY: NLA_U16
- *                    WGALLOWEDIP_A_IPADDR: NLA_MIN_LEN(struct in_addr), struct in_addr or struct in6_addr
- *                    WGALLOWEDIP_A_CIDR_MASK: NLA_U8
- *                0: NLA_NESTED
- *                    ...
- *                0: NLA_NESTED
- *                    ...
- *                ...
- *            WGPEER_A_PROTOCOL_VERSION: NLA_U32
- *        0: NLA_NESTED
- *            ...
- *        ...
- *
- * It is possible that all of the allowed IPs of a single peer will not
- * fit within a single netlink message. In that case, the same peer will
- * be written in the following message, except it will only contain
- * WGPEER_A_PUBLIC_KEY and WGPEER_A_ALLOWEDIPS. This may occur several
- * times in a row for the same peer. It is then up to the receiver to
- * coalesce adjacent peers. Likewise, it is possible that all peers will
- * not fit within a single message. So, subsequent peers will be sent
- * in following messages, except those will only contain WGDEVICE_A_IFNAME
- * and WGDEVICE_A_PEERS. It is then up to the receiver to coalesce these
- * messages to form the complete list of peers.
- *
- * Since this is an NLA_F_DUMP command, the final message will always be
- * NLMSG_DONE, even if an error occurs. However, this NLMSG_DONE message
- * contains an integer error code. It is either zero or a negative error
- * code corresponding to the errno.
- *
- * WG_CMD_SET_DEVICE
- * -----------------
- *
- * May only be called via NLM_F_REQUEST. The command should contain the
- * following tree of nested items, containing one but not both of
- * WGDEVICE_A_IFINDEX and WGDEVICE_A_IFNAME:
- *
- *    WGDEVICE_A_IFINDEX: NLA_U32
- *    WGDEVICE_A_IFNAME: NLA_NUL_STRING, maxlen IFNAMSIZ - 1
- *    WGDEVICE_A_FLAGS: NLA_U32, 0 or WGDEVICE_F_REPLACE_PEERS if all current
- *                      peers should be removed prior to adding the list below.
- *    WGDEVICE_A_PRIVATE_KEY: len WG_KEY_LEN, all zeros to remove
- *    WGDEVICE_A_LISTEN_PORT: NLA_U16, 0 to choose randomly
- *    WGDEVICE_A_FWMARK: NLA_U32, 0 to disable
- *    WGDEVICE_A_PEERS: NLA_NESTED
- *        0: NLA_NESTED
- *            WGPEER_A_PUBLIC_KEY: len WG_KEY_LEN
- *            WGPEER_A_FLAGS: NLA_U32, 0 and/or WGPEER_F_REMOVE_ME if the
- *                            specified peer should not exist at the end of the
- *                            operation, rather than added/updated and/or
- *                            WGPEER_F_REPLACE_ALLOWEDIPS if all current allowed
- *                            IPs of this peer should be removed prior to adding
- *                            the list below and/or WGPEER_F_UPDATE_ONLY if the
- *                            peer should only be set if it already exists.
- *            WGPEER_A_PRESHARED_KEY: len WG_KEY_LEN, all zeros to remove
- *            WGPEER_A_ENDPOINT: struct sockaddr_in or struct sockaddr_in6
- *            WGPEER_A_PERSISTENT_KEEPALIVE_INTERVAL: NLA_U16, 0 to disable
- *            WGPEER_A_ALLOWEDIPS: NLA_NESTED
- *                0: NLA_NESTED
- *                    WGALLOWEDIP_A_FAMILY: NLA_U16
- *                    WGALLOWEDIP_A_IPADDR: struct in_addr or struct in6_addr
- *                    WGALLOWEDIP_A_CIDR_MASK: NLA_U8
- *                    WGALLOWEDIP_A_FLAGS: NLA_U32, WGALLOWEDIP_F_REMOVE_ME if
- *                                         the specified IP should be removed;
- *                                         otherwise, this IP will be added if
- *                                         it is not already present.
- *                0: NLA_NESTED
- *                    ...
- *                0: NLA_NESTED
- *                    ...
- *                ...
- *            WGPEER_A_PROTOCOL_VERSION: NLA_U32, should not be set or used at
- *                                       all by most users of this API, as the
- *                                       most recent protocol will be used when
- *                                       this is unset. Otherwise, must be set
- *                                       to 1.
- *        0: NLA_NESTED
- *            ...
- *        ...
- *
- * It is possible that the amount of configuration data exceeds that of
- * the maximum message length accepted by the kernel. In that case, several
- * messages should be sent one after another, with each successive one
- * filling in information not contained in the prior. Note that if
- * WGDEVICE_F_REPLACE_PEERS is specified in the first message, it probably
- * should not be specified in fragments that come after, so that the list
- * of peers is only cleared the first time but appended after. Likewise for
- * peers, if WGPEER_F_REPLACE_ALLOWEDIPS is specified in the first message
- * of a peer, it likely should not be specified in subsequent fragments.
- *
- * If an error occurs, NLMSG_ERROR will reply containing an errno.
  */
 
 #ifndef _WG_UAPI_WIREGUARD_H
-- 
2.51.0

Re: [PATCH net-next v3 04/11] netlink: specs: add specification for wireguard

[Jason A. Donenfeld]

On Wed, Nov 05, 2025 at 06:32:13PM +0000, Asbjørn Sloth Tønnesen wrote:
> +name: wireguard
> +protocol: genetlink-legacy

I'll need to do my own reading, I guess, but what is going on with this
"legacy" business? Is there some newer genetlink that falls outside of
versioning?

> +c-family-name: wg-genl-name
> +c-version-name: wg-genl-version
> +max-by-define: true
> +
> +definitions:
> +  -
> +    name-prefix: wg-

There's lots of control over the C output here. Why can't there also be
a top-level c-function-prefix attribute, so that patch 10/11 is
unnecessary? Stack traces for wireguard all include wg_; why pollute
this with the new "wireguard_" ones?

> +        doc: The index is set as ``0`` in ``DUMP``, and unused in ``DO``.

I think get/set might match the operations better than the underlying
netlink verbs? This is a doc comment specific to getting and setting.

On the other hand, maybe that's an implementation detail and doesn't
need to be specified? Or if you think rigidity is important, we should
specify 0 in both directions and then validate it to ensure userspace
sends 0 (all userspaces currently do).

> +        The kernel will then return several messages (``NLM_F_MULTI``).
> +        It is possible that all of the allowed IPs of a single peer
> +        will not fit within a single netlink message. In that case, the
> +        same peer will be written in the following message, except it will
> +        only contain ``WGPEER_A_PUBLIC_KEY`` and ``WGPEER_A_ALLOWEDIPS``.
> +        This may occur several times in a row for the same peer.
> +        It is then up to the receiver to coalesce adjacent peers.
> +        Likewise, it is possible that all peers will not fit within a
> +        single message.
> +        So, subsequent peers will be sent in following messages,
> +        except those will only contain ``WGDEVICE_A_IFNAME`` and
> +        ``WGDEVICE_A_PEERS``. It is then up to the receiver to coalesce
> +        these messages to form the complete list of peers.

There's an extra line break before the "So," that wasn't there in the
original.


> +        While this command does accept the other ``WGDEVICE_A_*``
> +        attributes, for compatibility reasons, but they are ignored
> +        by this command, and should not be used in requests.

Either "While" or ", but" but not both.

However, can we actually just make this strict? No userspaces send
random attributes in a GET. Nothing should break.

> +      dump:
> +        pre: wireguard-nl-get-device-start
> +        post: wireguard-nl-get-device-done

Oh, or, the wg_ prefix can be defined here (instead of wireguard_, per
my 10/11 comment above).

> +        # request only uses ifindex | ifname, but keep .maxattr as is
> +        request: &all-attrs
> +          attributes:
> +            - ifindex
> +            - ifname
> +            - private-key
> +            - public-key
> +            - flags
> +            - listen-port
> +            - fwmark
> +            - peers

As mentioned earlier, maybe this can be reduced to ifindex+ifname.

> +        It is possible that the amount of configuration data exceeds that
> +        of the maximum message length accepted by the kernel.
> +        In that case, several messages should be sent one after another,
> +        with each successive one filling in information not contained in
> +        the prior.
> +        Note that if ``WGDEVICE_F_REPLACE_PEERS`` is specified in the first
> +        message, it probably should not be specified in fragments that come
> +        after, so that the list of peers is only cleared the first time but
> +        appended after.
> +        Likewise for peers, if ``WGPEER_F_REPLACE_ALLOWEDIPS`` is specified
> +        in the first message of a peer, it likely should not be specified
> +        in subsequent fragments.

More odd linebreaks added. Either it's a new paragraph or it isn't. Keep
this how it was before?

Jason

Re: [PATCH net-next v3 04/11] netlink: specs: add specification for wireguard

[Asbjørn Sloth Tønnesen]

Hi Jason,

Thanks for the review.

On 11/18/25 2:15 AM, Jason A. Donenfeld wrote:
> On Wed, Nov 05, 2025 at 06:32:13PM +0000, Asbjørn Sloth Tønnesen wrote:
>> +name: wireguard
>> +protocol: genetlink-legacy
> 
> I'll need to do my own reading, I guess, but what is going on with this
> "legacy" business? Is there some newer genetlink that falls outside of
> versioning?

There's a few reasons why the stricter genetlink doesn't fit:
- Less flexible with C naming (breaking UAPI).
- Doesn't allow C struct types.

diff -Naur Documentation/netlink/genetlink{,-legacy}.yaml
>> +c-family-name: wg-genl-name
>> +c-version-name: wg-genl-version
>> +max-by-define: true
>> +
>> +definitions:
>> +  -
>> +    name-prefix: wg-
> 
> There's lots of control over the C output here. Why can't there also be
> a top-level c-function-prefix attribute, so that patch 10/11 is
> unnecessary? Stack traces for wireguard all include wg_; why pollute
> this with the new "wireguard_" ones?

It could also be just "c-prefix".

Jakub, WDYT?

>> +        doc: The index is set as ``0`` in ``DUMP``, and unused in ``DO``.
> 
> I think get/set might match the operations better than the underlying
> netlink verbs? This is a doc comment specific to getting and setting.

Sure, I could change that. Originally opted for the C-style, as I kept the
C-style from your original text in the rest of the doc comments.

> On the other hand, maybe that's an implementation detail and doesn't
> need to be specified? Or if you think rigidity is important, we should
> specify 0 in both directions and then validate it to ensure userspace
> sends 0 (all userspaces currently do).

As is, the YNL-based clients are taking advantage of it not being validated.
Changing that would require adding some new YNL type properties.
See this series[1] for my earlier attempt to extend YNL in this area.

[1] https://lore.kernel.org/r/20251022182701.250897-1-ast@fiberby.net/

The modern way would be to use multi-attrs, but I don't think it's worth it
to transition, you mainly save a few bytes of overhead.

WGDEVICE_A_IFINDEX
WGDEVICE_A_PEERS2: NLA_NESTED
   WGPEER_A_PUBLIC_KEY
   [..]
   WGPEER_A_ALLOWEDIPS2: NLA_NESTED
     WGALLOWEDIP_A_FAMILY
     [..]
   WGPEER_A_ALLOWEDIPS2: NLA_NESTED
     WGALLOWEDIP_A_FAMILY
     [..]
WGDEVICE_A_PEERS2: NLA_NESTED
   [..]

>> +        The kernel will then return several messages (``NLM_F_MULTI``).
>> +        It is possible that all of the allowed IPs of a single peer
>> +        will not fit within a single netlink message. In that case, the
>> +        same peer will be written in the following message, except it will
>> +        only contain ``WGPEER_A_PUBLIC_KEY`` and ``WGPEER_A_ALLOWEDIPS``.
>> +        This may occur several times in a row for the same peer.
>> +        It is then up to the receiver to coalesce adjacent peers.
>> +        Likewise, it is possible that all peers will not fit within a
>> +        single message.
>> +        So, subsequent peers will be sent in following messages,
>> +        except those will only contain ``WGDEVICE_A_IFNAME`` and
>> +        ``WGDEVICE_A_PEERS``. It is then up to the receiver to coalesce
>> +        these messages to form the complete list of peers.
> 
> There's an extra line break before the "So," that wasn't there in the
> original.

It's collapsed when rendered, added them to reduce diff stat for future changes.
A new paragraph in .rst requires a double line break, but I can remove them.

>> +        While this command does accept the other ``WGDEVICE_A_*``
>> +        attributes, for compatibility reasons, but they are ignored
>> +        by this command, and should not be used in requests.
> 
> Either "While" or ", but" but not both.
> 
> However, can we actually just make this strict? No userspaces send
> random attributes in a GET. Nothing should break.

I agree that nothing should break, just tried to avoid changing UAPI in the
spec commit, but by moving the split ops conversion patch, then I can eliminate
this before adding the spec.

>> +      dump:
>> +        pre: wireguard-nl-get-device-start
>> +        post: wireguard-nl-get-device-done
> 
> Oh, or, the wg_ prefix can be defined here (instead of wireguard_, per
> my 10/11 comment above).

The key here is the missing ones, I renamed these for alignment with
doit and dumpit which can't be customized at this time.

Re: [PATCH net-next v3 04/11] netlink: specs: add specification for wireguard

[Jason A. Donenfeld]

Hi Asbjørn,

On Tue, Nov 18, 2025 at 12:08:20PM +0000, Asbjørn Sloth Tønnesen wrote:
> > I'll need to do my own reading, I guess, but what is going on with this
> > "legacy" business? Is there some newer genetlink that falls outside of
> > versioning?
> 
> There's a few reasons why the stricter genetlink doesn't fit:
> - Less flexible with C naming (breaking UAPI).
> - Doesn't allow C struct types.
> 
> diff -Naur Documentation/netlink/genetlink{,-legacy}.yaml

Oh, thanks, useful diff. So the protocol didn't change, persay, but the
non-legacy one just firms up some of the floppiness of what was done
before. Makes sense.

> > There's lots of control over the C output here. Why can't there also be
> > a top-level c-function-prefix attribute, so that patch 10/11 is
> > unnecessary? Stack traces for wireguard all include wg_; why pollute
> > this with the new "wireguard_" ones?
> 
> It could also be just "c-prefix".

Works for me.

> >> +      dump:
> >> +        pre: wireguard-nl-get-device-start
> >> +        post: wireguard-nl-get-device-done
> > 
> > Oh, or, the wg_ prefix can be defined here (instead of wireguard_, per
> > my 10/11 comment above).
> 
> The key here is the missing ones, I renamed these for alignment with
> doit and dumpit which can't be customized at this time.

Oh, interesting. So actually, the c-prefix thing would let you ditch
this too, and it'd be more consistent.

> > On the other hand, maybe that's an implementation detail and doesn't
> > need to be specified? Or if you think rigidity is important, we should
> > specify 0 in both directions and then validate it to ensure userspace
> > sends 0 (all userspaces currently do).
> 
> As is, the YNL-based clients are taking advantage of it not being validated.
> Changing that would require adding some new YNL type properties.
> See this series[1] for my earlier attempt to extend YNL in this area.
> 
> [1] https://lore.kernel.org/r/20251022182701.250897-1-ast@fiberby.net/
> 
> The modern way would be to use multi-attrs, but I don't think it's worth it
> to transition, you mainly save a few bytes of overhead.

Oh, huh, interesting. In libmnl, this parameter is referred to as "type"
instead of index, so it was natural to stick 0 there. It looks like so
does Go's netlink library, but in wgctrl-go, Matt stuck index there.

So... darn. We're stuck with this being poorly defined. I guess we can
have as the text something like:

    The index/type parameter is unused on SET_DEVICE operations and is zero on GET_DEVICE operations.

> WGDEVICE_A_IFINDEX
> WGDEVICE_A_PEERS2: NLA_NESTED
>    WGPEER_A_PUBLIC_KEY
>    [..]
>    WGPEER_A_ALLOWEDIPS2: NLA_NESTED
>      WGALLOWEDIP_A_FAMILY
>      [..]
>    WGPEER_A_ALLOWEDIPS2: NLA_NESTED
>      WGALLOWEDIP_A_FAMILY
>      [..]
> WGDEVICE_A_PEERS2: NLA_NESTED
>    [..]

Def not worth it. But good to know about for future protocols.

> >> +        While this command does accept the other ``WGDEVICE_A_*``
> >> +        attributes, for compatibility reasons, but they are ignored
> >> +        by this command, and should not be used in requests.
> > 
> > Either "While" or ", but" but not both.
> > 
> > However, can we actually just make this strict? No userspaces send
> > random attributes in a GET. Nothing should break.
> 
> I agree that nothing should break, just tried to avoid changing UAPI in the
> spec commit, but by moving the split ops conversion patch, then I can eliminate
> this before adding the spec.

Okay, great, let's do that.

Thanks a bunch.

Jason

Re: [PATCH net-next v3 04/11] netlink: specs: add specification for wireguard

[Asbjørn Sloth Tønnesen]

On 11/18/25 3:07 PM, Jason A. Donenfeld wrote:
> On Tue, Nov 18, 2025 at 12:08:20PM +0000, Asbjørn Sloth Tønnesen wrote:
>>> There's lots of control over the C output here. Why can't there also be
>>> a top-level c-function-prefix attribute, so that patch 10/11 is
>>> unnecessary? Stack traces for wireguard all include wg_; why pollute
>>> this with the new "wireguard_" ones?
>>
>> It could also be just "c-prefix".
> 
> Works for me.

Unfortunately, it isn't that simple.

The functions are defined as:
name = c_lower(f"{family.ident_name}-nl-{op_name}-doit")
name = c_lower(f"{family.ident_name}-nl-{op_name}-dumpit")
and
name = c_lower(f"{family.ident_name}-nl-{op_name}-{op_mode}it")

The "c-prefix" would replace "family.ident_name" aka. "wireguard",
but the "-nl-" would remain, which isn't in the current naming.

So "c-function-prefix" or something might work better.

My idea with "c-prefix" was to also cover the family and version defines,
but they are eg. WG_GENL_NAME where the default would be *_FAMILY_NAME.

>>>> +      dump:
>>>> +        pre: wireguard-nl-get-device-start
>>>> +        post: wireguard-nl-get-device-done
>>>
>>> Oh, or, the wg_ prefix can be defined here (instead of wireguard_, per
>>> my 10/11 comment above).
>>
>> The key here is the missing ones, I renamed these for alignment with
>> doit and dumpit which can't be customized at this time.
> 
> Oh, interesting. So actually, the c-prefix thing would let you ditch
> this too, and it'd be more consistent.

The pre and post still needs to be defined as they aren't used by default.

Re: [PATCH net-next v3 04/11] netlink: specs: add specification for wireguard

[Jason A. Donenfeld]

On Tue, Nov 18, 2025 at 09:59:45PM +0000, Asbjørn Sloth Tønnesen wrote:
> So "c-function-prefix" or something might work better.

Also fine with me. I'd just like consistent function naming, one way or
another.

Re: [PATCH net-next v3 04/11] netlink: specs: add specification for wireguard

[Jakub Kicinski]

On Tue, 18 Nov 2025 23:52:30 +0100 Jason A. Donenfeld wrote:
> On Tue, Nov 18, 2025 at 09:59:45PM +0000, Asbjørn Sloth Tønnesen wrote:
> > So "c-function-prefix" or something might work better.  
> 
> Also fine with me. I'd just like consistent function naming, one way or
> another.

IIUC we're talking about the prefix for the kernel C codegen?
Feels a bit like a one-off feature to me, but if we care deeply about
it let's add it as a CLI param to the codegen. I don't think it's
necessary to include this in the YAML spec.

Re: [PATCH net-next v3 04/11] netlink: specs: add specification for wireguard

[Asbjørn Sloth Tønnesen]

On 11/19/25 12:50 AM, Jakub Kicinski wrote:
> On Tue, 18 Nov 2025 23:52:30 +0100 Jason A. Donenfeld wrote:
>> On Tue, Nov 18, 2025 at 09:59:45PM +0000, Asbjørn Sloth Tønnesen wrote:
>>> So "c-function-prefix" or something might work better.
>>
>> Also fine with me. I'd just like consistent function naming, one way or
>> another.
> 
> IIUC we're talking about the prefix for the kernel C codegen?
> Feels a bit like a one-off feature to me, but if we care deeply about
> it let's add it as a CLI param to the codegen. I don't think it's
> necessary to include this in the YAML spec.

IIUC then adding it as a CLI param is more work, and just moves family details
to ynl-regen, might as well skip the CLI param then and hack it in the codegen.

Before posting any new patches, I would like to get consensus on this.

Options:

A) As-is and all 4 functions gets renamed.

    Stacktraces, gdb scripts, tracing etc. changes due to the 4 function renames.

B) Add a "operations"->"function-prefix" in YAML, only one funtion gets renamed.

    wg_get_device_start(), wg_get_device_dump() and wg_get_device_done() keep
    their names, while wg_set_device() gets renamed to wg_set_device_doit().

    This compliments the existing "name-prefix" (which is used for the UAPI enum names).

    Documentation/netlink/genetlink-legacy.yaml |  6 ++++++
    tools/net/ynl/pyynl/ynl_gen_c.py            | 13 +++++++++----
    2 files changed, 15 insertions(+), 4 deletions(-)

C) Add a "call" in YAML to override the default doit/dumpit names.

    All 4 functions can keep their current names.

    This compliments the existing "pre" and "post" (which are only rendered when set).

    How these map to struct genl_split_ops:

       kind \ YAML | pre        | call    | post
      -------------+------------+---------+------------
       do          | .pre_doit  | .doit   | .post_doit
       dump        | .start     | .dumpit | .done

D) Add it as a ynl_gen_c.py CLI param and make ynl-regen set it for wireguard?

While A is a no-op, then B is simpler to implement than option C, as the names are
generated in multiple places, where as it's simple to just use a prefix.
So option C might require some more refactoring, than is worth it for an one-off feature.
OTOH option C is more flexible than option B.

Jason, would option B work for you?

Jakub, would option B or C be acceptable?

WDYT?

Re: [PATCH net-next v3 04/11] netlink: specs: add specification for wireguard

[Jason A. Donenfeld]

On Wed, Nov 19, 2025 at 8:20 PM Asbjørn Sloth Tønnesen <ast@fiberby.net> wrote:
> B) Add a "operations"->"function-prefix" in YAML, only one funtion gets renamed.
>
>     wg_get_device_start(), wg_get_device_dump() and wg_get_device_done() keep
>     their names, while wg_set_device() gets renamed to wg_set_device_doit().
>
>     This compliments the existing "name-prefix" (which is used for the UAPI enum names).
>
>     Documentation/netlink/genetlink-legacy.yaml |  6 ++++++
>     tools/net/ynl/pyynl/ynl_gen_c.py            | 13 +++++++++----
>     2 files changed, 15 insertions(+), 4 deletions(-)
>
> Jason, would option B work for you?

So just wg_set_device() -> wg_set_device_doit()? That seems quite fine
to me. And it's probably a better name, too, given that it corresponds
with device_dump. It makes both of those follow the form "wg_{genl
verb}_{nl verb}". I like it.

Jason

Re: [PATCH net-next v3 04/11] netlink: specs: add specification for wireguard

[Asbjørn Sloth Tønnesen]

On 11/19/25 7:22 PM, Jason A. Donenfeld wrote:
> On Wed, Nov 19, 2025 at 8:20 PM Asbjørn Sloth Tønnesen <ast@fiberby.net> wrote:
>> B) Add a "operations"->"function-prefix" in YAML, only one funtion gets renamed.
>>
>>      wg_get_device_start(), wg_get_device_dump() and wg_get_device_done() keep
>>      their names, while wg_set_device() gets renamed to wg_set_device_doit().
>>
>>      This compliments the existing "name-prefix" (which is used for the UAPI enum names).
>>
>>      Documentation/netlink/genetlink-legacy.yaml |  6 ++++++
>>      tools/net/ynl/pyynl/ynl_gen_c.py            | 13 +++++++++----
>>      2 files changed, 15 insertions(+), 4 deletions(-)
>>
>> Jason, would option B work for you?
> 
> So just wg_set_device() -> wg_set_device_doit()? 

Sorry, no, wg_get_device_dump{,it} too.

Did my test on top of my branch were they are still renamed, so overlooked that rename.

Re: [PATCH net-next v3 04/11] netlink: specs: add specification for wireguard

[Jason A. Donenfeld]

On Wed, Nov 19, 2025 at 8:47 PM Asbjørn Sloth Tønnesen <ast@fiberby.net> wrote:
>
> On 11/19/25 7:22 PM, Jason A. Donenfeld wrote:
> > On Wed, Nov 19, 2025 at 8:20 PM Asbjørn Sloth Tønnesen <ast@fiberby.net> wrote:
> >> B) Add a "operations"->"function-prefix" in YAML, only one funtion gets renamed.
> >>
> >>      wg_get_device_start(), wg_get_device_dump() and wg_get_device_done() keep
> >>      their names, while wg_set_device() gets renamed to wg_set_device_doit().
> >>
> >>      This compliments the existing "name-prefix" (which is used for the UAPI enum names).
> >>
> >>      Documentation/netlink/genetlink-legacy.yaml |  6 ++++++
> >>      tools/net/ynl/pyynl/ynl_gen_c.py            | 13 +++++++++----
> >>      2 files changed, 15 insertions(+), 4 deletions(-)
> >>
> >> Jason, would option B work for you?
> >
> > So just wg_set_device() -> wg_set_device_doit()?
>
> Sorry, no, wg_get_device_dump{,it} too.

Fine by me.

Re: [PATCH net-next v3 04/11] netlink: specs: add specification for wireguard

[Jakub Kicinski]

On Wed, 19 Nov 2025 19:19:28 +0000 Asbjørn Sloth Tønnesen wrote:
> >> Also fine with me. I'd just like consistent function naming, one way or
> >> another.  
> > 
> > IIUC we're talking about the prefix for the kernel C codegen?
> > Feels a bit like a one-off feature to me, but if we care deeply about
> > it let's add it as a CLI param to the codegen. I don't think it's
> > necessary to include this in the YAML spec.  
> 
> IIUC then adding it as a CLI param is more work, and just moves family details
> to ynl-regen, might as well skip the CLI param then and hack it in the codegen.
> 
> Before posting any new patches, I would like to get consensus on this.

The reason other C naming tunables exist (for legacy families!)
is because we need to give enough hints to C code gen to be able
to use existing kernel uAPI headers.

Random "naming preferences" do not belong in the spec. The spec 
is primarily for user space, and it's used by 4 languages already.

[PATCH net-next v3 05/11] uapi: wireguard: move enum wg_cmd

[Asbjørn Sloth Tønnesen]

This patch moves enum wg_cmd to the end of the file, where
ynl-gen would like to generate it.

This is an incremental step towards adopting an UAPI header
generated by ynl-gen. This is split out to keep the patches readable.

This is a trivial patch with no behavioural changes intended.

Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
---
 include/uapi/linux/wireguard.h | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/include/uapi/linux/wireguard.h b/include/uapi/linux/wireguard.h
index dee4401e0b5d..3ebfffd61269 100644
--- a/include/uapi/linux/wireguard.h
+++ b/include/uapi/linux/wireguard.h
@@ -11,13 +11,6 @@
 
 #define WG_KEY_LEN 32
 
-enum wg_cmd {
-	WG_CMD_GET_DEVICE,
-	WG_CMD_SET_DEVICE,
-	__WG_CMD_MAX
-};
-#define WG_CMD_MAX (__WG_CMD_MAX - 1)
-
 enum wgdevice_flag {
 	WGDEVICE_F_REPLACE_PEERS = 1U << 0,
 	__WGDEVICE_F_ALL = WGDEVICE_F_REPLACE_PEERS
@@ -73,4 +66,12 @@ enum wgallowedip_attribute {
 };
 #define WGALLOWEDIP_A_MAX (__WGALLOWEDIP_A_LAST - 1)
 
+enum wg_cmd {
+	WG_CMD_GET_DEVICE,
+	WG_CMD_SET_DEVICE,
+
+	__WG_CMD_MAX
+};
+#define WG_CMD_MAX (__WG_CMD_MAX - 1)
+
 #endif /* _WG_UAPI_WIREGUARD_H */
-- 
2.51.0

[PATCH net-next v3 06/11] uapi: wireguard: move flag enums

[Asbjørn Sloth Tønnesen]

Move the wg*_flag enums, so that they are defined above the
attribute set enums, as ynl-gen would place them.

This is an incremental step towards adopting an UAPI header
generated by ynl-gen. This is split out to keep the patches readable.

This is a trivial patch with no behavioural changes intended.

Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
---
 include/uapi/linux/wireguard.h | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/include/uapi/linux/wireguard.h b/include/uapi/linux/wireguard.h
index 3ebfffd61269..a2815f4f2910 100644
--- a/include/uapi/linux/wireguard.h
+++ b/include/uapi/linux/wireguard.h
@@ -15,6 +15,20 @@ enum wgdevice_flag {
 	WGDEVICE_F_REPLACE_PEERS = 1U << 0,
 	__WGDEVICE_F_ALL = WGDEVICE_F_REPLACE_PEERS
 };
+
+enum wgpeer_flag {
+	WGPEER_F_REMOVE_ME = 1U << 0,
+	WGPEER_F_REPLACE_ALLOWEDIPS = 1U << 1,
+	WGPEER_F_UPDATE_ONLY = 1U << 2,
+	__WGPEER_F_ALL = WGPEER_F_REMOVE_ME | WGPEER_F_REPLACE_ALLOWEDIPS |
+			 WGPEER_F_UPDATE_ONLY
+};
+
+enum wgallowedip_flag {
+	WGALLOWEDIP_F_REMOVE_ME = 1U << 0,
+	__WGALLOWEDIP_F_ALL = WGALLOWEDIP_F_REMOVE_ME
+};
+
 enum wgdevice_attribute {
 	WGDEVICE_A_UNSPEC,
 	WGDEVICE_A_IFINDEX,
@@ -29,13 +43,6 @@ enum wgdevice_attribute {
 };
 #define WGDEVICE_A_MAX (__WGDEVICE_A_LAST - 1)
 
-enum wgpeer_flag {
-	WGPEER_F_REMOVE_ME = 1U << 0,
-	WGPEER_F_REPLACE_ALLOWEDIPS = 1U << 1,
-	WGPEER_F_UPDATE_ONLY = 1U << 2,
-	__WGPEER_F_ALL = WGPEER_F_REMOVE_ME | WGPEER_F_REPLACE_ALLOWEDIPS |
-			 WGPEER_F_UPDATE_ONLY
-};
 enum wgpeer_attribute {
 	WGPEER_A_UNSPEC,
 	WGPEER_A_PUBLIC_KEY,
@@ -52,10 +59,6 @@ enum wgpeer_attribute {
 };
 #define WGPEER_A_MAX (__WGPEER_A_LAST - 1)
 
-enum wgallowedip_flag {
-	WGALLOWEDIP_F_REMOVE_ME = 1U << 0,
-	__WGALLOWEDIP_F_ALL = WGALLOWEDIP_F_REMOVE_ME
-};
 enum wgallowedip_attribute {
 	WGALLOWEDIP_A_UNSPEC,
 	WGALLOWEDIP_A_FAMILY,
-- 
2.51.0

Re: [PATCH net-next v3 06/11] uapi: wireguard: move flag enums

[Jason A. Donenfeld]

On Wed, Nov 05, 2025 at 06:32:15PM +0000, Asbjørn Sloth Tønnesen wrote:
> Move the wg*_flag enums, so that they are defined above the
> attribute set enums, as ynl-gen would place them.
> 
> This is an incremental step towards adopting an UAPI header
> generated by ynl-gen. This is split out to keep the patches readable.
> 
> This is a trivial patch with no behavioural changes intended.

Can we call the subject of this commit `wireguard: uapi: ...`, and same
for the other one?

[PATCH net-next v3 07/11] uapi: wireguard: generate header with ynl-gen

[Asbjørn Sloth Tønnesen]

Use ynl-gen to generate the UAPI header for wireguard.

The cosmetic changes in this patch, confirms that the spec is aligned
with the implementation, and ensures that it stays in sync.

Changes in generated header:
* Trivial include guard rename.
* Trivial white space changes.
* Trivial comment changes.
* Precompute bitflags in ynl-gen (see [1]).
* Drop __*_F_ALL constants (see [1]).

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

No behavioural changes intended.

Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
---
 drivers/net/wireguard/netlink.c |  6 +++---
 include/uapi/linux/wireguard.h  | 37 ++++++++++++++++-----------------
 2 files changed, 21 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireguard/netlink.c b/drivers/net/wireguard/netlink.c
index 682678d24a9f..f9bed135000f 100644
--- a/drivers/net/wireguard/netlink.c
+++ b/drivers/net/wireguard/netlink.c
@@ -26,7 +26,7 @@ static const struct nla_policy device_policy[WGDEVICE_A_MAX + 1] = {
 	[WGDEVICE_A_IFNAME]		= { .type = NLA_NUL_STRING, .len = IFNAMSIZ - 1 },
 	[WGDEVICE_A_PRIVATE_KEY]	= NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
 	[WGDEVICE_A_PUBLIC_KEY]		= NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
-	[WGDEVICE_A_FLAGS]		= NLA_POLICY_MASK(NLA_U32, __WGDEVICE_F_ALL),
+	[WGDEVICE_A_FLAGS]		= NLA_POLICY_MASK(NLA_U32, 0x1),
 	[WGDEVICE_A_LISTEN_PORT]	= { .type = NLA_U16 },
 	[WGDEVICE_A_FWMARK]		= { .type = NLA_U32 },
 	[WGDEVICE_A_PEERS]		= NLA_POLICY_NESTED_ARRAY(peer_policy),
@@ -35,7 +35,7 @@ static const struct nla_policy device_policy[WGDEVICE_A_MAX + 1] = {
 static const struct nla_policy peer_policy[WGPEER_A_MAX + 1] = {
 	[WGPEER_A_PUBLIC_KEY]				= NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
 	[WGPEER_A_PRESHARED_KEY]			= NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
-	[WGPEER_A_FLAGS]				= NLA_POLICY_MASK(NLA_U32, __WGPEER_F_ALL),
+	[WGPEER_A_FLAGS]				= NLA_POLICY_MASK(NLA_U32, 0x7),
 	[WGPEER_A_ENDPOINT]				= NLA_POLICY_MIN_LEN(sizeof(struct sockaddr)),
 	[WGPEER_A_PERSISTENT_KEEPALIVE_INTERVAL]	= { .type = NLA_U16 },
 	[WGPEER_A_LAST_HANDSHAKE_TIME]			= NLA_POLICY_EXACT_LEN(sizeof(struct __kernel_timespec)),
@@ -49,7 +49,7 @@ static const struct nla_policy allowedip_policy[WGALLOWEDIP_A_MAX + 1] = {
 	[WGALLOWEDIP_A_FAMILY]		= { .type = NLA_U16 },
 	[WGALLOWEDIP_A_IPADDR]		= NLA_POLICY_MIN_LEN(sizeof(struct in_addr)),
 	[WGALLOWEDIP_A_CIDR_MASK]	= { .type = NLA_U8 },
-	[WGALLOWEDIP_A_FLAGS]		= NLA_POLICY_MASK(NLA_U32, __WGALLOWEDIP_F_ALL),
+	[WGALLOWEDIP_A_FLAGS]		= NLA_POLICY_MASK(NLA_U32, 0x1),
 };
 
 static struct wg_device *lookup_interface(struct nlattr **attrs,
diff --git a/include/uapi/linux/wireguard.h b/include/uapi/linux/wireguard.h
index a2815f4f2910..dc3924d0c552 100644
--- a/include/uapi/linux/wireguard.h
+++ b/include/uapi/linux/wireguard.h
@@ -1,32 +1,28 @@
-/* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT */
-/*
- * Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
- */
+/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) */
+/* Do not edit directly, auto-generated from: */
+/*	Documentation/netlink/specs/wireguard.yaml */
+/* YNL-GEN uapi header */
 
-#ifndef _WG_UAPI_WIREGUARD_H
-#define _WG_UAPI_WIREGUARD_H
+#ifndef _UAPI_LINUX_WIREGUARD_H
+#define _UAPI_LINUX_WIREGUARD_H
 
-#define WG_GENL_NAME "wireguard"
-#define WG_GENL_VERSION 1
+#define WG_GENL_NAME	"wireguard"
+#define WG_GENL_VERSION	1
 
-#define WG_KEY_LEN 32
+#define WG_KEY_LEN	32
 
 enum wgdevice_flag {
-	WGDEVICE_F_REPLACE_PEERS = 1U << 0,
-	__WGDEVICE_F_ALL = WGDEVICE_F_REPLACE_PEERS
+	WGDEVICE_F_REPLACE_PEERS = 1,
 };
 
 enum wgpeer_flag {
-	WGPEER_F_REMOVE_ME = 1U << 0,
-	WGPEER_F_REPLACE_ALLOWEDIPS = 1U << 1,
-	WGPEER_F_UPDATE_ONLY = 1U << 2,
-	__WGPEER_F_ALL = WGPEER_F_REMOVE_ME | WGPEER_F_REPLACE_ALLOWEDIPS |
-			 WGPEER_F_UPDATE_ONLY
+	WGPEER_F_REMOVE_ME = 1,
+	WGPEER_F_REPLACE_ALLOWEDIPS = 2,
+	WGPEER_F_UPDATE_ONLY = 4,
 };
 
 enum wgallowedip_flag {
-	WGALLOWEDIP_F_REMOVE_ME = 1U << 0,
-	__WGALLOWEDIP_F_ALL = WGALLOWEDIP_F_REMOVE_ME
+	WGALLOWEDIP_F_REMOVE_ME = 1,
 };
 
 enum wgdevice_attribute {
@@ -39,6 +35,7 @@ enum wgdevice_attribute {
 	WGDEVICE_A_LISTEN_PORT,
 	WGDEVICE_A_FWMARK,
 	WGDEVICE_A_PEERS,
+
 	__WGDEVICE_A_LAST
 };
 #define WGDEVICE_A_MAX (__WGDEVICE_A_LAST - 1)
@@ -55,6 +52,7 @@ enum wgpeer_attribute {
 	WGPEER_A_TX_BYTES,
 	WGPEER_A_ALLOWEDIPS,
 	WGPEER_A_PROTOCOL_VERSION,
+
 	__WGPEER_A_LAST
 };
 #define WGPEER_A_MAX (__WGPEER_A_LAST - 1)
@@ -65,6 +63,7 @@ enum wgallowedip_attribute {
 	WGALLOWEDIP_A_IPADDR,
 	WGALLOWEDIP_A_CIDR_MASK,
 	WGALLOWEDIP_A_FLAGS,
+
 	__WGALLOWEDIP_A_LAST
 };
 #define WGALLOWEDIP_A_MAX (__WGALLOWEDIP_A_LAST - 1)
@@ -77,4 +76,4 @@ enum wg_cmd {
 };
 #define WG_CMD_MAX (__WG_CMD_MAX - 1)
 
-#endif /* _WG_UAPI_WIREGUARD_H */
+#endif /* _UAPI_LINUX_WIREGUARD_H */
-- 
2.51.0

Re: [PATCH net-next v3 07/11] uapi: wireguard: generate header with ynl-gen

[Jason A. Donenfeld]

On Wed, Nov 05, 2025 at 06:32:16PM +0000, Asbjørn Sloth Tønnesen wrote:
> Use ynl-gen to generate the UAPI header for wireguard.
> diff --git a/include/uapi/linux/wireguard.h b/include/uapi/linux/wireguard.h
> index a2815f4f2910..dc3924d0c552 100644
> --- a/include/uapi/linux/wireguard.h
> +++ b/include/uapi/linux/wireguard.h
> @@ -1,32 +1,28 @@
> -/* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT */
> -/*
> - * Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
> - */
> +/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) */
> +/* Do not edit directly, auto-generated from: */
> +/*	Documentation/netlink/specs/wireguard.yaml */
> +/* YNL-GEN uapi header */

Same desire here -- can this get auto generated at compile time (or in
headers_install time).

Jason

Re: [PATCH net-next v3 07/11] uapi: wireguard: generate header with ynl-gen

[Jakub Kicinski]

On Tue, 18 Nov 2025 16:17:21 +0100 Jason A. Donenfeld wrote:
> On Wed, Nov 05, 2025 at 06:32:16PM +0000, Asbjørn Sloth Tønnesen wrote:
> > Use ynl-gen to generate the UAPI header for wireguard.
> > diff --git a/include/uapi/linux/wireguard.h b/include/uapi/linux/wireguard.h
> > index a2815f4f2910..dc3924d0c552 100644
> > --- a/include/uapi/linux/wireguard.h
> > +++ b/include/uapi/linux/wireguard.h
> > @@ -1,32 +1,28 @@
> > -/* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT */
> > -/*
> > - * Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
> > - */
> > +/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) */
> > +/* Do not edit directly, auto-generated from: */
> > +/*	Documentation/netlink/specs/wireguard.yaml */
> > +/* YNL-GEN uapi header */  
> 
> Same desire here -- can this get auto generated at compile time (or in
> headers_install time).

IMHO generating uAPI on the fly has more downsides than benefits.
For one thing people grepping the code and looking and lxr will
never find the definition. All the user space code in tools/ is
generated at build time, but the amount of kernel code we generate
is not significant at this stage. Not significant enough to complicate
everyone's life..

Re: [PATCH net-next v3 07/11] uapi: wireguard: generate header with ynl-gen

[Jason A. Donenfeld]

On Tue, Nov 18, 2025 at 04:53:15PM -0800, Jakub Kicinski wrote:
> On Tue, 18 Nov 2025 16:17:21 +0100 Jason A. Donenfeld wrote:
> > On Wed, Nov 05, 2025 at 06:32:16PM +0000, Asbjørn Sloth Tønnesen wrote:
> > > Use ynl-gen to generate the UAPI header for wireguard.
> > > diff --git a/include/uapi/linux/wireguard.h b/include/uapi/linux/wireguard.h
> > > index a2815f4f2910..dc3924d0c552 100644
> > > --- a/include/uapi/linux/wireguard.h
> > > +++ b/include/uapi/linux/wireguard.h
> > > @@ -1,32 +1,28 @@
> > > -/* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT */
> > > -/*
> > > - * Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
> > > - */
> > > +/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) */
> > > +/* Do not edit directly, auto-generated from: */
> > > +/*	Documentation/netlink/specs/wireguard.yaml */
> > > +/* YNL-GEN uapi header */  
> > 
> > Same desire here -- can this get auto generated at compile time (or in
> > headers_install time).
> 
> IMHO generating uAPI on the fly has more downsides than benefits.
> For one thing people grepping the code and looking and lxr will
> never find the definition. All the user space code in tools/ is
> generated at build time, but the amount of kernel code we generate
> is not significant at this stage. Not significant enough to complicate
> everyone's life..

I was thinking that doing this automatically at compile-time or
install-time would be _less_ complicated, not more, since everything
would be kept in sync automatically and such. But alright, so be it.

[PATCH net-next v3 08/11] tools: ynl: add sample for wireguard

[Asbjørn Sloth Tønnesen]

Add a sample application for wireguard, using the generated C library,

The main benefit of this is to exercise the generated library,
which might be useful for future selftests.

In order to support usage with a pre-YNL wireguard.h in /usr/include,
then the former guard is added to Makefile.deps as well.

Example:
  $ make -C tools/net/ynl/lib
  $ make -C tools/net/ynl/generated
  $ make -C tools/net/ynl/samples wireguard
  $ ./tools/net/ynl/samples/wireguard
  usage: ./tools/net/ynl/samples/wireguard <ifindex|ifname>
  $ sudo ./tools/net/ynl/samples/wireguard wg-test
  Interface 3: wg-test
      Peer 6adfb183a4a2c94a2f92dab5ade762a4788[...]:
          Data: rx: 42 / tx: 42 bytes
          Allowed IPs:
              0.0.0.0/0
              ::/0

Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
---
 MAINTAINERS                       |   1 +
 tools/net/ynl/Makefile.deps       |   2 +
 tools/net/ynl/samples/.gitignore  |   1 +
 tools/net/ynl/samples/wireguard.c | 104 ++++++++++++++++++++++++++++++
 4 files changed, 108 insertions(+)
 create mode 100644 tools/net/ynl/samples/wireguard.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 35cd289899f7..1c9c21ff2c97 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27651,6 +27651,7 @@ L:	netdev@vger.kernel.org
 S:	Maintained
 F:	Documentation/netlink/specs/wireguard.yaml
 F:	drivers/net/wireguard/
+F:	tools/net/ynl/samples/wireguard.c
 F:	tools/testing/selftests/wireguard/
 
 WISTRON LAPTOP BUTTON DRIVER
diff --git a/tools/net/ynl/Makefile.deps b/tools/net/ynl/Makefile.deps
index 865fd2e8519e..a9a5348b31a3 100644
--- a/tools/net/ynl/Makefile.deps
+++ b/tools/net/ynl/Makefile.deps
@@ -48,3 +48,5 @@ CFLAGS_tc:= $(call get_hdr_inc,__LINUX_RTNETLINK_H,rtnetlink.h) \
 	$(call get_hdr_inc,_TC_SKBEDIT_H,tc_act/tc_skbedit.h) \
 	$(call get_hdr_inc,_TC_TUNNEL_KEY_H,tc_act/tc_tunnel_key.h)
 CFLAGS_tcp_metrics:=$(call get_hdr_inc,_LINUX_TCP_METRICS_H,tcp_metrics.h)
+CFLAGS_wireguard:=$(call get_hdr_inc,_LINUX_WIREGUARD_H,wireguard.h) \
+	-D _WG_UAPI_WIREGUARD_H # alternate pre-YNL guard
diff --git a/tools/net/ynl/samples/.gitignore b/tools/net/ynl/samples/.gitignore
index 7f5fca7682d7..09c61e4c18cd 100644
--- a/tools/net/ynl/samples/.gitignore
+++ b/tools/net/ynl/samples/.gitignore
@@ -7,3 +7,4 @@ rt-addr
 rt-link
 rt-route
 tc
+wireguard
diff --git a/tools/net/ynl/samples/wireguard.c b/tools/net/ynl/samples/wireguard.c
new file mode 100644
index 000000000000..43f3551eb101
--- /dev/null
+++ b/tools/net/ynl/samples/wireguard.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <arpa/inet.h>
+#include <string.h>
+#include <stdio.h>
+#include <errno.h>
+#include <ynl.h>
+
+#include "wireguard-user.h"
+
+static void print_allowed_ip(const struct wireguard_wgallowedip *aip)
+{
+	char addr_out[INET6_ADDRSTRLEN];
+
+	if (!inet_ntop(aip->family, aip->ipaddr, addr_out, sizeof(addr_out))) {
+		addr_out[0] = '?';
+		addr_out[1] = '\0';
+	}
+	printf("\t\t\t%s/%u\n", addr_out, aip->cidr_mask);
+}
+
+/* Only printing public key in this demo. For better key formatting,
+ * use the constant-time implementation as found in wireguard-tools.
+ */
+static void print_peer_header(const struct wireguard_wgpeer *peer)
+{
+	unsigned int i;
+	uint8_t *key = peer->public_key;
+	unsigned int len = peer->_len.public_key;
+
+	if (len != 32)
+		return;
+	printf("\tPeer ");
+	for (i = 0; i < len; i++)
+		printf("%02x", key[i]);
+	printf(":\n");
+}
+
+static void print_peer(const struct wireguard_wgpeer *peer)
+{
+	unsigned int i;
+
+	print_peer_header(peer);
+	printf("\t\tData: rx: %llu / tx: %llu bytes\n",
+	       peer->rx_bytes, peer->tx_bytes);
+	printf("\t\tAllowed IPs:\n");
+	for (i = 0; i < peer->_count.allowedips; i++)
+		print_allowed_ip(&peer->allowedips[i]);
+}
+
+static void build_request(struct wireguard_get_device_req *req, char *arg)
+{
+	char *endptr;
+	int ifindex;
+
+	ifindex = strtol(arg, &endptr, 0);
+	if (endptr != arg + strlen(arg) || errno != 0)
+		ifindex = 0;
+	if (ifindex > 0)
+		wireguard_get_device_req_set_ifindex(req, ifindex);
+	else
+		wireguard_get_device_req_set_ifname(req, arg);
+}
+
+int main(int argc, char **argv)
+{
+	struct wireguard_get_device_list *devs;
+	struct wireguard_get_device_req *req;
+	struct ynl_sock *ys;
+
+	if (argc < 2) {
+		fprintf(stderr, "usage: %s <ifindex|ifname>\n", argv[0]);
+		return 1;
+	}
+
+	req = wireguard_get_device_req_alloc();
+	build_request(req, argv[1]);
+
+	ys = ynl_sock_create(&ynl_wireguard_family, NULL);
+	if (!ys)
+		return 2;
+
+	devs = wireguard_get_device_dump(ys, req);
+	if (!devs)
+		goto err_close;
+
+	ynl_dump_foreach(devs, d) {
+		unsigned int i;
+
+		printf("Interface %d: %s\n", d->ifindex, d->ifname);
+		for (i = 0; i < d->_count.peers; i++)
+			print_peer(&d->peers[i]);
+	}
+	wireguard_get_device_list_free(devs);
+	wireguard_get_device_req_free(req);
+	ynl_sock_destroy(ys);
+
+	return 0;
+
+err_close:
+	fprintf(stderr, "YNL (%d): %s\n", ys->err.code, ys->err.msg);
+	wireguard_get_device_req_free(req);
+	ynl_sock_destroy(ys);
+	return 3;
+}
-- 
2.51.0

Re: [PATCH net-next v3 08/11] tools: ynl: add sample for wireguard

[Jason A. Donenfeld]

On Wed, Nov 05, 2025 at 06:32:17PM +0000, Asbjørn Sloth Tønnesen wrote:
> +CFLAGS_wireguard:=$(call get_hdr_inc,_LINUX_WIREGUARD_H,wireguard.h) \
> +	-D _WG_UAPI_WIREGUARD_H # alternate pre-YNL guard

I don't totally grok what's going on here. As I understand it, this
makefile creates `wireguard-user.h` in the generated/ include path,
which has all the various netlink wrapper declarations. And then this
also references, somehow, include/uapi/linux/wireguard.h, for the constants.
For some reason, you're then defining _WG_UAPI_WIREGUARD_H here, so that
wireguard.h from /usr/include doesn't clash. But also, why would it?
Isn't this just a matter of placing $(src)/include/uapi earlier in the
include file path?

Jason

Re: [PATCH net-next v3 08/11] tools: ynl: add sample for wireguard

[Asbjørn Sloth Tønnesen]

On 11/18/25 3:20 PM, Jason A. Donenfeld wrote:
> On Wed, Nov 05, 2025 at 06:32:17PM +0000, Asbjørn Sloth Tønnesen wrote:
>> +CFLAGS_wireguard:=$(call get_hdr_inc,_LINUX_WIREGUARD_H,wireguard.h) \
>> +	-D _WG_UAPI_WIREGUARD_H # alternate pre-YNL guard
> 
> I don't totally grok what's going on here. As I understand it, this
> makefile creates `wireguard-user.h` in the generated/ include path,
> which has all the various netlink wrapper declarations. And then this
> also references, somehow, include/uapi/linux/wireguard.h, for the constants.
> For some reason, you're then defining _WG_UAPI_WIREGUARD_H here, so that
> wireguard.h from /usr/include doesn't clash. But also, why would it?
> Isn't this just a matter of placing $(src)/include/uapi earlier in the
> include file path?

The aim is to use the generated in-tree header, while avoiding making a
copy, and avoiding the system header.

As an example then in tools/net/ynl/generated/Makefile:

%-user.o: %-user.c %-user.h
         @echo -e "\tCC $@"
         @$(COMPILE.c) $(CFLAGS_$*) -o $@ $<

Where for the "wireguard-user.o" target, then "$(CFLAGS_$*)" expands to
"$CFLAGS_wireguard".

CFLAGS_wireguard has two parts the normal one similar to the other families,
and a transitional extra guard.

The header guard in the old UAPI header is "_WG_UAPI_WIREGUARD_H".
The header guard in the new UAPI header in-tree is "_UAPI_LINUX_WIREGUARD_H".
The header guard in the new UAPI header in-system is "_LINUX_WIREGUARD_H".

Linux uapi headers are installed using scripts/headers_install.sh, which
transforms the headers slightly, one of these transformations is to alter
the header guard, stripping the _UAPI in the beginning of the guard.

So "get_hdr_inc=-D$(1) -include $(UAPI_PATH)/linux/$(2)" does:
1) Defines the in-system guard
2) Includes the in-tree header

The purpose of defining the in-system guard is disable the include in
the code, as it's header guard is already defined.

I added the extra transitional define of the old UAPI guard, so that
it also works on systems with the old header installed in /usr.
This extra line can be removed in a few releases, when we don't care
about compiling these tools on a system with the old header installed.

Re: [PATCH net-next v3 08/11] tools: ynl: add sample for wireguard

[Jason A. Donenfeld]

On Tue, Nov 18, 2025 at 6:16 PM Asbjørn Sloth Tønnesen <ast@fiberby.net> wrote:
> This extra line can be removed in a few releases, when we don't care
> about compiling these tools on a system with the old header installed.

Sounds good. I'll put this on my calendar to revisit in 6 months.

Jason

[PATCH net-next v3 09/11] wireguard: netlink: convert to split ops

[Asbjørn Sloth Tønnesen]

This patch converts wireguard from using legacy struct genl_ops
to struct genl_split_ops, by applying the same transformation
as genl_cmd_full_to_split() would otherwise do at runtime.

WGDEVICE_A_MAX is swapped for WGDEVICE_A_PEERS, while they are
currently equivalent, then .maxattr should be the maximum attribute
that a given command supports, which might not be WGDEVICE_A_MAX.

This is an incremental step towards adopting netlink policy code
generated by ynl-gen, ensuring that the code and spec is aligned.

This is a trivial patch with no behavioural changes intended.

Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
---
 drivers/net/wireguard/netlink.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireguard/netlink.c b/drivers/net/wireguard/netlink.c
index f9bed135000f..7fecc25bd781 100644
--- a/drivers/net/wireguard/netlink.c
+++ b/drivers/net/wireguard/netlink.c
@@ -616,28 +616,30 @@ static int wg_set_device(struct sk_buff *skb, struct genl_info *info)
 	return ret;
 }
 
-static const struct genl_ops genl_ops[] = {
+static const struct genl_split_ops wireguard_nl_ops[] = {
 	{
 		.cmd = WG_CMD_GET_DEVICE,
 		.start = wg_get_device_start,
 		.dumpit = wg_get_device_dump,
 		.done = wg_get_device_done,
-		.flags = GENL_UNS_ADMIN_PERM
+		.policy = device_policy,
+		.maxattr = WGDEVICE_A_PEERS,
+		.flags = GENL_UNS_ADMIN_PERM | GENL_CMD_CAP_DUMP,
 	}, {
 		.cmd = WG_CMD_SET_DEVICE,
 		.doit = wg_set_device,
-		.flags = GENL_UNS_ADMIN_PERM
+		.policy = device_policy,
+		.maxattr = WGDEVICE_A_PEERS,
+		.flags = GENL_UNS_ADMIN_PERM | GENL_CMD_CAP_DO,
 	}
 };
 
 static struct genl_family genl_family __ro_after_init = {
-	.ops = genl_ops,
-	.n_ops = ARRAY_SIZE(genl_ops),
+	.split_ops = wireguard_nl_ops,
+	.n_split_ops = ARRAY_SIZE(wireguard_nl_ops),
 	.name = WG_GENL_NAME,
 	.version = WG_GENL_VERSION,
-	.maxattr = WGDEVICE_A_MAX,
 	.module = THIS_MODULE,
-	.policy = device_policy,
 	.netnsok = true
 };
 
-- 
2.51.0

[PATCH net-next v3 10/11] wireguard: netlink: rename netlink handlers

[Asbjørn Sloth Tønnesen]

Rename netlink handlers to use the naming expected by ynl-gen.

This is an incremental step towards adopting netlink command
definitions generated by ynl-gen.

This is a trivial patch with no behavioural changes intended.

Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
---
 drivers/net/wireguard/netlink.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireguard/netlink.c b/drivers/net/wireguard/netlink.c
index 7fecc25bd781..ff1549fe55e2 100644
--- a/drivers/net/wireguard/netlink.c
+++ b/drivers/net/wireguard/netlink.c
@@ -199,7 +199,7 @@ get_peer(struct wg_peer *peer, struct sk_buff *skb, struct dump_ctx *ctx)
 	return -EMSGSIZE;
 }
 
-static int wg_get_device_start(struct netlink_callback *cb)
+static int wireguard_nl_get_device_start(struct netlink_callback *cb)
 {
 	struct wg_device *wg;
 
@@ -210,7 +210,8 @@ static int wg_get_device_start(struct netlink_callback *cb)
 	return 0;
 }
 
-static int wg_get_device_dump(struct sk_buff *skb, struct netlink_callback *cb)
+static int wireguard_nl_get_device_dumpit(struct sk_buff *skb,
+					  struct netlink_callback *cb)
 {
 	struct wg_peer *peer, *next_peer_cursor;
 	struct dump_ctx *ctx = DUMP_CTX(cb);
@@ -304,7 +305,7 @@ static int wg_get_device_dump(struct sk_buff *skb, struct netlink_callback *cb)
 	 */
 }
 
-static int wg_get_device_done(struct netlink_callback *cb)
+static int wireguard_nl_get_device_done(struct netlink_callback *cb)
 {
 	struct dump_ctx *ctx = DUMP_CTX(cb);
 
@@ -502,7 +503,8 @@ static int set_peer(struct wg_device *wg, struct nlattr **attrs)
 	return ret;
 }
 
-static int wg_set_device(struct sk_buff *skb, struct genl_info *info)
+static int wireguard_nl_set_device_doit(struct sk_buff *skb,
+					struct genl_info *info)
 {
 	struct wg_device *wg = lookup_interface(info->attrs, skb);
 	u32 flags = 0;
@@ -619,15 +621,15 @@ static int wg_set_device(struct sk_buff *skb, struct genl_info *info)
 static const struct genl_split_ops wireguard_nl_ops[] = {
 	{
 		.cmd = WG_CMD_GET_DEVICE,
-		.start = wg_get_device_start,
-		.dumpit = wg_get_device_dump,
-		.done = wg_get_device_done,
+		.start = wireguard_nl_get_device_start,
+		.dumpit = wireguard_nl_get_device_dumpit,
+		.done = wireguard_nl_get_device_done,
 		.policy = device_policy,
 		.maxattr = WGDEVICE_A_PEERS,
 		.flags = GENL_UNS_ADMIN_PERM | GENL_CMD_CAP_DUMP,
 	}, {
 		.cmd = WG_CMD_SET_DEVICE,
-		.doit = wg_set_device,
+		.doit = wireguard_nl_set_device_doit,
 		.policy = device_policy,
 		.maxattr = WGDEVICE_A_PEERS,
 		.flags = GENL_UNS_ADMIN_PERM | GENL_CMD_CAP_DO,
-- 
2.51.0

[PATCH net-next v3 11/11] wireguard: netlink: generate netlink code

[Asbjørn Sloth Tønnesen]

This patch adopts netlink policy and command definitions as
generated by ynl-gen, thus completing the conversion to YNL.

Given that the old and new policy is functionally identical, and
just moved to a new file, then it serves to verify that the policy
in the spec in identical to the previous policy code.

The new files are covered by drivers/net/wireguard/ pattern in
MAINTAINERS.

No behavioural changes intended.

Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
---
 drivers/net/wireguard/Makefile      |  1 +
 drivers/net/wireguard/netlink.c     | 64 +++---------------------
 drivers/net/wireguard/netlink_gen.c | 77 +++++++++++++++++++++++++++++
 drivers/net/wireguard/netlink_gen.h | 29 +++++++++++
 4 files changed, 114 insertions(+), 57 deletions(-)
 create mode 100644 drivers/net/wireguard/netlink_gen.c
 create mode 100644 drivers/net/wireguard/netlink_gen.h

diff --git a/drivers/net/wireguard/Makefile b/drivers/net/wireguard/Makefile
index dbe1f8514efc..ae4b479cddbd 100644
--- a/drivers/net/wireguard/Makefile
+++ b/drivers/net/wireguard/Makefile
@@ -14,4 +14,5 @@ wireguard-y += allowedips.o
 wireguard-y += ratelimiter.o
 wireguard-y += cookie.o
 wireguard-y += netlink.o
+wireguard-y += netlink_gen.o
 obj-$(CONFIG_WIREGUARD) := wireguard.o
diff --git a/drivers/net/wireguard/netlink.c b/drivers/net/wireguard/netlink.c
index ff1549fe55e2..6a7e522e3a78 100644
--- a/drivers/net/wireguard/netlink.c
+++ b/drivers/net/wireguard/netlink.c
@@ -9,6 +9,7 @@
 #include "socket.h"
 #include "queueing.h"
 #include "messages.h"
+#include "netlink_gen.h"
 
 #include <uapi/linux/wireguard.h>
 
@@ -18,39 +19,6 @@
 #include <crypto/utils.h>
 
 static struct genl_family genl_family;
-static const struct nla_policy peer_policy[WGPEER_A_MAX + 1];
-static const struct nla_policy allowedip_policy[WGALLOWEDIP_A_MAX + 1];
-
-static const struct nla_policy device_policy[WGDEVICE_A_MAX + 1] = {
-	[WGDEVICE_A_IFINDEX]		= { .type = NLA_U32 },
-	[WGDEVICE_A_IFNAME]		= { .type = NLA_NUL_STRING, .len = IFNAMSIZ - 1 },
-	[WGDEVICE_A_PRIVATE_KEY]	= NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
-	[WGDEVICE_A_PUBLIC_KEY]		= NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
-	[WGDEVICE_A_FLAGS]		= NLA_POLICY_MASK(NLA_U32, 0x1),
-	[WGDEVICE_A_LISTEN_PORT]	= { .type = NLA_U16 },
-	[WGDEVICE_A_FWMARK]		= { .type = NLA_U32 },
-	[WGDEVICE_A_PEERS]		= NLA_POLICY_NESTED_ARRAY(peer_policy),
-};
-
-static const struct nla_policy peer_policy[WGPEER_A_MAX + 1] = {
-	[WGPEER_A_PUBLIC_KEY]				= NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
-	[WGPEER_A_PRESHARED_KEY]			= NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
-	[WGPEER_A_FLAGS]				= NLA_POLICY_MASK(NLA_U32, 0x7),
-	[WGPEER_A_ENDPOINT]				= NLA_POLICY_MIN_LEN(sizeof(struct sockaddr)),
-	[WGPEER_A_PERSISTENT_KEEPALIVE_INTERVAL]	= { .type = NLA_U16 },
-	[WGPEER_A_LAST_HANDSHAKE_TIME]			= NLA_POLICY_EXACT_LEN(sizeof(struct __kernel_timespec)),
-	[WGPEER_A_RX_BYTES]				= { .type = NLA_U64 },
-	[WGPEER_A_TX_BYTES]				= { .type = NLA_U64 },
-	[WGPEER_A_ALLOWEDIPS]				= NLA_POLICY_NESTED_ARRAY(allowedip_policy),
-	[WGPEER_A_PROTOCOL_VERSION]			= { .type = NLA_U32 }
-};
-
-static const struct nla_policy allowedip_policy[WGALLOWEDIP_A_MAX + 1] = {
-	[WGALLOWEDIP_A_FAMILY]		= { .type = NLA_U16 },
-	[WGALLOWEDIP_A_IPADDR]		= NLA_POLICY_MIN_LEN(sizeof(struct in_addr)),
-	[WGALLOWEDIP_A_CIDR_MASK]	= { .type = NLA_U8 },
-	[WGALLOWEDIP_A_FLAGS]		= NLA_POLICY_MASK(NLA_U32, 0x1),
-};
 
 static struct wg_device *lookup_interface(struct nlattr **attrs,
 					  struct sk_buff *skb)
@@ -199,7 +167,7 @@ get_peer(struct wg_peer *peer, struct sk_buff *skb, struct dump_ctx *ctx)
 	return -EMSGSIZE;
 }
 
-static int wireguard_nl_get_device_start(struct netlink_callback *cb)
+int wireguard_nl_get_device_start(struct netlink_callback *cb)
 {
 	struct wg_device *wg;
 
@@ -210,8 +178,8 @@ static int wireguard_nl_get_device_start(struct netlink_callback *cb)
 	return 0;
 }
 
-static int wireguard_nl_get_device_dumpit(struct sk_buff *skb,
-					  struct netlink_callback *cb)
+int wireguard_nl_get_device_dumpit(struct sk_buff *skb,
+				   struct netlink_callback *cb)
 {
 	struct wg_peer *peer, *next_peer_cursor;
 	struct dump_ctx *ctx = DUMP_CTX(cb);
@@ -305,7 +273,7 @@ static int wireguard_nl_get_device_dumpit(struct sk_buff *skb,
 	 */
 }
 
-static int wireguard_nl_get_device_done(struct netlink_callback *cb)
+int wireguard_nl_get_device_done(struct netlink_callback *cb)
 {
 	struct dump_ctx *ctx = DUMP_CTX(cb);
 
@@ -503,8 +471,8 @@ static int set_peer(struct wg_device *wg, struct nlattr **attrs)
 	return ret;
 }
 
-static int wireguard_nl_set_device_doit(struct sk_buff *skb,
-					struct genl_info *info)
+int wireguard_nl_set_device_doit(struct sk_buff *skb,
+				 struct genl_info *info)
 {
 	struct wg_device *wg = lookup_interface(info->attrs, skb);
 	u32 flags = 0;
@@ -618,24 +586,6 @@ static int wireguard_nl_set_device_doit(struct sk_buff *skb,
 	return ret;
 }
 
-static const struct genl_split_ops wireguard_nl_ops[] = {
-	{
-		.cmd = WG_CMD_GET_DEVICE,
-		.start = wireguard_nl_get_device_start,
-		.dumpit = wireguard_nl_get_device_dumpit,
-		.done = wireguard_nl_get_device_done,
-		.policy = device_policy,
-		.maxattr = WGDEVICE_A_PEERS,
-		.flags = GENL_UNS_ADMIN_PERM | GENL_CMD_CAP_DUMP,
-	}, {
-		.cmd = WG_CMD_SET_DEVICE,
-		.doit = wireguard_nl_set_device_doit,
-		.policy = device_policy,
-		.maxattr = WGDEVICE_A_PEERS,
-		.flags = GENL_UNS_ADMIN_PERM | GENL_CMD_CAP_DO,
-	}
-};
-
 static struct genl_family genl_family __ro_after_init = {
 	.split_ops = wireguard_nl_ops,
 	.n_split_ops = ARRAY_SIZE(wireguard_nl_ops),
diff --git a/drivers/net/wireguard/netlink_gen.c b/drivers/net/wireguard/netlink_gen.c
new file mode 100644
index 000000000000..f95fa133778f
--- /dev/null
+++ b/drivers/net/wireguard/netlink_gen.c
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+/* Do not edit directly, auto-generated from: */
+/*	Documentation/netlink/specs/wireguard.yaml */
+/* YNL-GEN kernel source */
+
+#include <net/netlink.h>
+#include <net/genetlink.h>
+
+#include "netlink_gen.h"
+
+#include <uapi/linux/wireguard.h>
+#include <linux/time_types.h>
+
+/* Common nested types */
+const struct nla_policy wireguard_wgallowedip_nl_policy[WGALLOWEDIP_A_FLAGS + 1] = {
+	[WGALLOWEDIP_A_FAMILY] = { .type = NLA_U16, },
+	[WGALLOWEDIP_A_IPADDR] = NLA_POLICY_MIN_LEN(4),
+	[WGALLOWEDIP_A_CIDR_MASK] = { .type = NLA_U8, },
+	[WGALLOWEDIP_A_FLAGS] = NLA_POLICY_MASK(NLA_U32, 0x1),
+};
+
+const struct nla_policy wireguard_wgpeer_nl_policy[WGPEER_A_PROTOCOL_VERSION + 1] = {
+	[WGPEER_A_PUBLIC_KEY] = NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
+	[WGPEER_A_PRESHARED_KEY] = NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
+	[WGPEER_A_FLAGS] = NLA_POLICY_MASK(NLA_U32, 0x7),
+	[WGPEER_A_ENDPOINT] = NLA_POLICY_MIN_LEN(16),
+	[WGPEER_A_PERSISTENT_KEEPALIVE_INTERVAL] = { .type = NLA_U16, },
+	[WGPEER_A_LAST_HANDSHAKE_TIME] = NLA_POLICY_EXACT_LEN(16),
+	[WGPEER_A_RX_BYTES] = { .type = NLA_U64, },
+	[WGPEER_A_TX_BYTES] = { .type = NLA_U64, },
+	[WGPEER_A_ALLOWEDIPS] = NLA_POLICY_NESTED_ARRAY(wireguard_wgallowedip_nl_policy),
+	[WGPEER_A_PROTOCOL_VERSION] = { .type = NLA_U32, },
+};
+
+/* WG_CMD_GET_DEVICE - dump */
+static const struct nla_policy wireguard_get_device_nl_policy[WGDEVICE_A_PEERS + 1] = {
+	[WGDEVICE_A_IFINDEX] = { .type = NLA_U32, },
+	[WGDEVICE_A_IFNAME] = { .type = NLA_NUL_STRING, .len = 15, },
+	[WGDEVICE_A_PRIVATE_KEY] = NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
+	[WGDEVICE_A_PUBLIC_KEY] = NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
+	[WGDEVICE_A_FLAGS] = NLA_POLICY_MASK(NLA_U32, 0x1),
+	[WGDEVICE_A_LISTEN_PORT] = { .type = NLA_U16, },
+	[WGDEVICE_A_FWMARK] = { .type = NLA_U32, },
+	[WGDEVICE_A_PEERS] = NLA_POLICY_NESTED_ARRAY(wireguard_wgpeer_nl_policy),
+};
+
+/* WG_CMD_SET_DEVICE - do */
+static const struct nla_policy wireguard_set_device_nl_policy[WGDEVICE_A_PEERS + 1] = {
+	[WGDEVICE_A_IFINDEX] = { .type = NLA_U32, },
+	[WGDEVICE_A_IFNAME] = { .type = NLA_NUL_STRING, .len = 15, },
+	[WGDEVICE_A_PRIVATE_KEY] = NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
+	[WGDEVICE_A_PUBLIC_KEY] = NLA_POLICY_EXACT_LEN(WG_KEY_LEN),
+	[WGDEVICE_A_FLAGS] = NLA_POLICY_MASK(NLA_U32, 0x1),
+	[WGDEVICE_A_LISTEN_PORT] = { .type = NLA_U16, },
+	[WGDEVICE_A_FWMARK] = { .type = NLA_U32, },
+	[WGDEVICE_A_PEERS] = NLA_POLICY_NESTED_ARRAY(wireguard_wgpeer_nl_policy),
+};
+
+/* Ops table for wireguard */
+const struct genl_split_ops wireguard_nl_ops[2] = {
+	{
+		.cmd		= WG_CMD_GET_DEVICE,
+		.start		= wireguard_nl_get_device_start,
+		.dumpit		= wireguard_nl_get_device_dumpit,
+		.done		= wireguard_nl_get_device_done,
+		.policy		= wireguard_get_device_nl_policy,
+		.maxattr	= WGDEVICE_A_PEERS,
+		.flags		= GENL_UNS_ADMIN_PERM | GENL_CMD_CAP_DUMP,
+	},
+	{
+		.cmd		= WG_CMD_SET_DEVICE,
+		.doit		= wireguard_nl_set_device_doit,
+		.policy		= wireguard_set_device_nl_policy,
+		.maxattr	= WGDEVICE_A_PEERS,
+		.flags		= GENL_UNS_ADMIN_PERM | GENL_CMD_CAP_DO,
+	},
+};
diff --git a/drivers/net/wireguard/netlink_gen.h b/drivers/net/wireguard/netlink_gen.h
new file mode 100644
index 000000000000..e635b1f5f0df
--- /dev/null
+++ b/drivers/net/wireguard/netlink_gen.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) */
+/* Do not edit directly, auto-generated from: */
+/*	Documentation/netlink/specs/wireguard.yaml */
+/* YNL-GEN kernel header */
+
+#ifndef _LINUX_WIREGUARD_GEN_H
+#define _LINUX_WIREGUARD_GEN_H
+
+#include <net/netlink.h>
+#include <net/genetlink.h>
+
+#include <uapi/linux/wireguard.h>
+#include <linux/time_types.h>
+
+/* Common nested types */
+extern const struct nla_policy wireguard_wgallowedip_nl_policy[WGALLOWEDIP_A_FLAGS + 1];
+extern const struct nla_policy wireguard_wgpeer_nl_policy[WGPEER_A_PROTOCOL_VERSION + 1];
+
+/* Ops table for wireguard */
+extern const struct genl_split_ops wireguard_nl_ops[2];
+
+int wireguard_nl_get_device_start(struct netlink_callback *cb);
+int wireguard_nl_get_device_done(struct netlink_callback *cb);
+
+int wireguard_nl_get_device_dumpit(struct sk_buff *skb,
+				   struct netlink_callback *cb);
+int wireguard_nl_set_device_doit(struct sk_buff *skb, struct genl_info *info);
+
+#endif /* _LINUX_WIREGUARD_GEN_H */
-- 
2.51.0

Re: [PATCH net-next v3 11/11] wireguard: netlink: generate netlink code

[Jason A. Donenfeld]

On Wed, Nov 05, 2025 at 06:32:20PM +0000, Asbjørn Sloth Tønnesen wrote:
>  drivers/net/wireguard/netlink_gen.c | 77 +++++++++++++++++++++++++++++
>  drivers/net/wireguard/netlink_gen.h | 29 +++++++++++
>  create mode 100644 drivers/net/wireguard/netlink_gen.c
>  create mode 100644 drivers/net/wireguard/netlink_gen.h
> +#include "netlink_gen.h"
> +// SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
> +/* Do not edit directly, auto-generated from: */
> +/*	Documentation/netlink/specs/wireguard.yaml */
> +/* YNL-GEN kernel source */

Similar to what's happening in the tools/ynl/samples build system,
instead of statically generating this, can you have this be generated at
build time, and placed into a generated/ folder that doesn't get checked
into git? I don't see the purpose of having to manually keep this in
check?

(And if for some reason, you refuse to do that, it'd be very nice if the
 DO NOT EDIT header of the file also had the command that generated it,
 in case I need to regenerate it later and can't remember how it was
 done, because I didn't do it the first time, etc. Go's generated files
 usually follow this pattern.

 But anyway, I think I'd prefer, if it's possible, to just have this
 generated at compile time.)

Jason

Re: [PATCH net-next v3 11/11] wireguard: netlink: generate netlink code

[Jason A. Donenfeld]

On Tue, Nov 18, 2025 at 04:15:20PM +0100, Jason A. Donenfeld wrote:
> On Wed, Nov 05, 2025 at 06:32:20PM +0000, Asbjørn Sloth Tønnesen wrote:
> >  drivers/net/wireguard/netlink_gen.c | 77 +++++++++++++++++++++++++++++
> >  drivers/net/wireguard/netlink_gen.h | 29 +++++++++++
> >  create mode 100644 drivers/net/wireguard/netlink_gen.c
> >  create mode 100644 drivers/net/wireguard/netlink_gen.h
> > +#include "netlink_gen.h"
> > +// SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
> > +/* Do not edit directly, auto-generated from: */
> > +/*	Documentation/netlink/specs/wireguard.yaml */
> > +/* YNL-GEN kernel source */
> 
> Similar to what's happening in the tools/ynl/samples build system,
> instead of statically generating this, can you have this be generated at
> build time, and placed into a generated/ folder that doesn't get checked
> into git? I don't see the purpose of having to manually keep this in
> check?

Grep, for example, for PERLASM in the lib/crypto code. There's certainly
precedent for doing this.

Re: [PATCH net-next v3 11/11] wireguard: netlink: generate netlink code

[Asbjørn Sloth Tønnesen]

On 11/18/25 3:15 PM, Jason A. Donenfeld wrote:
> On Wed, Nov 05, 2025 at 06:32:20PM +0000, Asbjørn Sloth Tønnesen wrote:
>>   drivers/net/wireguard/netlink_gen.c | 77 +++++++++++++++++++++++++++++
>>   drivers/net/wireguard/netlink_gen.h | 29 +++++++++++
>>   create mode 100644 drivers/net/wireguard/netlink_gen.c
>>   create mode 100644 drivers/net/wireguard/netlink_gen.h
>> +#include "netlink_gen.h"
>> +// SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
>> +/* Do not edit directly, auto-generated from: */
>> +/*	Documentation/netlink/specs/wireguard.yaml */
>> +/* YNL-GEN kernel source */
> 
> Similar to what's happening in the tools/ynl/samples build system,
> instead of statically generating this, can you have this be generated at
> build time, and placed into a generated/ folder that doesn't get checked
> into git? I don't see the purpose of having to manually keep this in
> check?
> 
> (And if for some reason, you refuse to do that, it'd be very nice if the
>   DO NOT EDIT header of the file also had the command that generated it,
>   in case I need to regenerate it later and can't remember how it was
>   done, because I didn't do it the first time, etc. Go's generated files
>   usually follow this pattern.
> 
>   But anyway, I think I'd prefer, if it's possible, to just have this
>   generated at compile time.)

The main value in having the generated kernel code in git, is that it can't
change accidentally, which makes it easy for patchwork to catch if output
changes without being a part of the commit.

I will leave it up to Donald and Jakub, if they want to allow these files to
be generated on-the-fly.

Alternatively, the generated files could be put under YNL in MAINTAINERS, so you
only maintain the spec, but not the generated output files.

I agree that there could be a note in the header about how to re-generate
the files, or just a link to the doc:

https://docs.kernel.org/userspace-api/netlink/intro-specs.html#generating-kernel-code

The easy to use regeneration tool is ynl-regen:
./tools/net/ynl/ynl-regen.sh                           # skip if output is newer than yaml
./tools/net/ynl/ynl-regen.sh -f                        # force, when working on ynl
./tools/net/ynl/ynl-regen.sh -p drivers/net/wireguard  # run on a subdir

Re: [PATCH net-next v3 11/11] wireguard: netlink: generate netlink code

[Jason A. Donenfeld]

On Tue, Nov 18, 2025 at 10:23:12PM +0000, Asbjørn Sloth Tønnesen wrote:
> On 11/18/25 3:15 PM, Jason A. Donenfeld wrote:
> > On Wed, Nov 05, 2025 at 06:32:20PM +0000, Asbjørn Sloth Tønnesen wrote:
> >>   drivers/net/wireguard/netlink_gen.c | 77 +++++++++++++++++++++++++++++
> >>   drivers/net/wireguard/netlink_gen.h | 29 +++++++++++
> >>   create mode 100644 drivers/net/wireguard/netlink_gen.c
> >>   create mode 100644 drivers/net/wireguard/netlink_gen.h
> >> +#include "netlink_gen.h"
> >> +// SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
> >> +/* Do not edit directly, auto-generated from: */
> >> +/*	Documentation/netlink/specs/wireguard.yaml */
> >> +/* YNL-GEN kernel source */
> > 
> > Similar to what's happening in the tools/ynl/samples build system,
> > instead of statically generating this, can you have this be generated at
> > build time, and placed into a generated/ folder that doesn't get checked
> > into git? I don't see the purpose of having to manually keep this in
> > check?
> > 
> > (And if for some reason, you refuse to do that, it'd be very nice if the
> >   DO NOT EDIT header of the file also had the command that generated it,
> >   in case I need to regenerate it later and can't remember how it was
> >   done, because I didn't do it the first time, etc. Go's generated files
> >   usually follow this pattern.
> > 
> >   But anyway, I think I'd prefer, if it's possible, to just have this
> >   generated at compile time.)
> 
> The main value in having the generated kernel code in git, is that it can't
> change accidentally, which makes it easy for patchwork to catch if output
> changes without being a part of the commit.
> 
> I will leave it up to Donald and Jakub, if they want to allow these files to
> be generated on-the-fly.

I mean, there is *tons* of generated code in the kernel. This is how it
works. And you *want the output to change when the tool changes*. That's
literally the point. It would be like if you wanted to check in all the
.o files, in case the compiler started generating different output, or
if you wanted the objtool output or anything else to be checked in. And
sheerly from a git perspective, it seems outrageous to touch a zillion
files every time the ynl code changes. Rather, the fact that it's
generated on the fly ensures that the ynl generator stays correctly
implemented. It's the best way to keep that code from rotting.

Jason

Re: [PATCH net-next v3 11/11] wireguard: netlink: generate netlink code

[Jakub Kicinski]

On Tue, 18 Nov 2025 23:51:37 +0100 Jason A. Donenfeld wrote:
> I mean, there is *tons* of generated code in the kernel. This is how it
> works. And you *want the output to change when the tool changes*. That's
> literally the point. It would be like if you wanted to check in all the
> .o files, in case the compiler started generating different output, or
> if you wanted the objtool output or anything else to be checked in. And
> sheerly from a git perspective, it seems outrageous to touch a zillion
> files every time the ynl code changes. Rather, the fact that it's
> generated on the fly ensures that the ynl generator stays correctly
> implemented. It's the best way to keep that code from rotting.

CI checks validate that the files are up to date.
There has been no churn to the kernel side of the generated code.
Let's be practical.

Re: [PATCH net-next v3 11/11] wireguard: netlink: generate netlink code

[Jason A. Donenfeld]

On Tue, Nov 18, 2025 at 05:00:45PM -0800, Jakub Kicinski wrote:
> On Tue, 18 Nov 2025 23:51:37 +0100 Jason A. Donenfeld wrote:
> > I mean, there is *tons* of generated code in the kernel. This is how it
> > works. And you *want the output to change when the tool changes*. That's
> > literally the point. It would be like if you wanted to check in all the
> > .o files, in case the compiler started generating different output, or
> > if you wanted the objtool output or anything else to be checked in. And
> > sheerly from a git perspective, it seems outrageous to touch a zillion
> > files every time the ynl code changes. Rather, the fact that it's
> > generated on the fly ensures that the ynl generator stays correctly
> > implemented. It's the best way to keep that code from rotting.
> 
> CI checks validate that the files are up to date.
> There has been no churn to the kernel side of the generated code.
> Let's be practical.

Okay, it sounds like neither of you want to do this. Darn. I really hate
having generated artifacts laying around that can be created efficiently
at compile time. But okay, so it goes. I guess we'll do that.

I would like to ask two things, then, which may or may not be possible:

1) Can we put this in drivers/net/wireguard/generated/netlink.{c.h}
   And then in the Makefile, do `wireguard-y += netlink.o generated/netlink.o`
   on one line like that. I prefer this to keeping it in the same
   directory with the awkward -gen suffix.

2) In the header of each generated file, automatically write out the
   command that was used to generate it. Here's an example of this good
   habit from Go: https://github.com/golang/go/blob/master/src/syscall/zsyscall_linux_amd64.go

Jason

Re: [PATCH net-next v3 11/11] wireguard: netlink: generate netlink code

[Jakub Kicinski]

On Thu, 20 Nov 2025 01:54:47 +0100 Jason A. Donenfeld wrote:
> On Tue, Nov 18, 2025 at 05:00:45PM -0800, Jakub Kicinski wrote:
> > On Tue, 18 Nov 2025 23:51:37 +0100 Jason A. Donenfeld wrote:  
> > > I mean, there is *tons* of generated code in the kernel. This is how it
> > > works. And you *want the output to change when the tool changes*. That's
> > > literally the point. It would be like if you wanted to check in all the
> > > .o files, in case the compiler started generating different output, or
> > > if you wanted the objtool output or anything else to be checked in. And
> > > sheerly from a git perspective, it seems outrageous to touch a zillion
> > > files every time the ynl code changes. Rather, the fact that it's
> > > generated on the fly ensures that the ynl generator stays correctly
> > > implemented. It's the best way to keep that code from rotting.  
> > 
> > CI checks validate that the files are up to date.
> > There has been no churn to the kernel side of the generated code.
> > Let's be practical.  
> 
> Okay, it sounds like neither of you want to do this. Darn. I really hate
> having generated artifacts laying around that can be created efficiently
> at compile time. But okay, so it goes. I guess we'll do that.
> 
> I would like to ask two things, then, which may or may not be possible:
> 
> 1) Can we put this in drivers/net/wireguard/generated/netlink.{c.h}
>    And then in the Makefile, do `wireguard-y += netlink.o generated/netlink.o`
>    on one line like that. I prefer this to keeping it in the same
>    directory with the awkward -gen suffix.

That should work, I think.

> 2) In the header of each generated file, automatically write out the
>    command that was used to generate it. Here's an example of this good
>    habit from Go: https://github.com/golang/go/blob/master/src/syscall/zsyscall_linux_amd64.go

You don't like the runes? :)

/* Do not edit directly, auto-generated from: */
/*	$YAML-path */
/* YNL-GEN [kernel|user|uapi] [source|header] */
/* YNL-ARG $extra-args */

Do you care about the exact cmdline of the python tool, or can we just
append:

/* To regenerate run: tools/net/ynl/ynl-regen.sh */

Re: [PATCH net-next v3 11/11] wireguard: netlink: generate netlink code

[Jason A. Donenfeld]

On Thu, Nov 20, 2025 at 3:44 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 20 Nov 2025 01:54:47 +0100 Jason A. Donenfeld wrote:
> > On Tue, Nov 18, 2025 at 05:00:45PM -0800, Jakub Kicinski wrote:
> > > On Tue, 18 Nov 2025 23:51:37 +0100 Jason A. Donenfeld wrote:
> > > > I mean, there is *tons* of generated code in the kernel. This is how it
> > > > works. And you *want the output to change when the tool changes*. That's
> > > > literally the point. It would be like if you wanted to check in all the
> > > > .o files, in case the compiler started generating different output, or
> > > > if you wanted the objtool output or anything else to be checked in. And
> > > > sheerly from a git perspective, it seems outrageous to touch a zillion
> > > > files every time the ynl code changes. Rather, the fact that it's
> > > > generated on the fly ensures that the ynl generator stays correctly
> > > > implemented. It's the best way to keep that code from rotting.
> > >
> > > CI checks validate that the files are up to date.
> > > There has been no churn to the kernel side of the generated code.
> > > Let's be practical.
> >
> > Okay, it sounds like neither of you want to do this. Darn. I really hate
> > having generated artifacts laying around that can be created efficiently
> > at compile time. But okay, so it goes. I guess we'll do that.
> >
> > I would like to ask two things, then, which may or may not be possible:
> >
> > 1) Can we put this in drivers/net/wireguard/generated/netlink.{c.h}
> >    And then in the Makefile, do `wireguard-y += netlink.o generated/netlink.o`
> >    on one line like that. I prefer this to keeping it in the same
> >    directory with the awkward -gen suffix.
>
> That should work, I think.
>
> > 2) In the header of each generated file, automatically write out the
> >    command that was used to generate it. Here's an example of this good
> >    habit from Go: https://github.com/golang/go/blob/master/src/syscall/zsyscall_linux_amd64.go
>
> You don't like the runes? :)
>
> /* Do not edit directly, auto-generated from: */
> /*      $YAML-path */
> /* YNL-GEN [kernel|user|uapi] [source|header] */
> /* YNL-ARG $extra-args */
>
> Do you care about the exact cmdline of the python tool, or can we just
> append:
>
> /* To regenerate run: tools/net/ynl/ynl-regen.sh */

The args are non-trivial, right? The idea is so that these files can
be regenerated in a few years when the ynl project has widely
succeeded and we've all paged this out of our minds and forgotten how
it all worked.

Re: [PATCH net-next v3 11/11] wireguard: netlink: generate netlink code

[Jakub Kicinski]

On Thu, 20 Nov 2025 03:46:39 +0100 Jason A. Donenfeld wrote:
> > Do you care about the exact cmdline of the python tool, or can we just
> > append:
> >
> > /* To regenerate run: tools/net/ynl/ynl-regen.sh */  
> 
> The args are non-trivial, right?

They aren't all that complicated TBH, quoting slightly modified from
tools/net/ynl/ynl-regen.sh:

    $TOOL --mode $mode --$type --spec $KDIR/$yaml_spec $extra_args -o $output

The line just gets quote long for my taste with all the paths in place.

Somewhere along the line we added --cmp-out to make sure output isn't
modified on every regen attempt (for the benefit of incremental builds).

> The idea is so that these files can be regenerated in a few years
> when the ynl project has widely succeeded and we've all paged this
> out of our minds and forgotten how it all worked.

We run ./tools/net/ynl/ynl-regen.sh in our CI, checking if anything
diverged. Primarily because in early days, when codegen was modified
more often, I was worried we'll break the generation for some of the
specs.

The documentation also basically says "create the fake header where 
you want the file to be and run ./tools/net/ynl/ynl-regen.sh".

https://docs.kernel.org/userspace-api/netlink/intro-specs.html#generating-kernel-code

Admittedly most of this comes down to "what Jakub found convenient
when developing the specs" :S

Re: [PATCH net-next v3 11/11] wireguard: netlink: generate netlink code

[Asbjørn Sloth Tønnesen]

On 11/20/25 12:54 AM, Jason A. Donenfeld wrote:
> On Tue, Nov 18, 2025 at 05:00:45PM -0800, Jakub Kicinski wrote:
>> On Tue, 18 Nov 2025 23:51:37 +0100 Jason A. Donenfeld wrote:
>>> I mean, there is *tons* of generated code in the kernel. This is how it
>>> works. And you *want the output to change when the tool changes*. That's
>>> literally the point. It would be like if you wanted to check in all the
>>> .o files, in case the compiler started generating different output, or
>>> if you wanted the objtool output or anything else to be checked in. And
>>> sheerly from a git perspective, it seems outrageous to touch a zillion
>>> files every time the ynl code changes. Rather, the fact that it's
>>> generated on the fly ensures that the ynl generator stays correctly
>>> implemented. It's the best way to keep that code from rotting.
>>
>> CI checks validate that the files are up to date.
>> There has been no churn to the kernel side of the generated code.
>> Let's be practical.
> 
> Okay, it sounds like neither of you want to do this. Darn. I really hate
> having generated artifacts laying around that can be created efficiently
> at compile time. But okay, so it goes. I guess we'll do that.

I generally agree, but given this generates code across the tree, then I
prefer this, as side-effects are more obvious.

To complete Jakub's earlier argument of not complicating everyone's life,
then this code generator is Python-based and depends on yaml and jsonschema.
Even doing compile-time generation for a single family, would elevate those
packages from developer-dependencies to build-dependencies.

> I would like to ask two things, then, which may or may not be possible:
> 
> 1) Can we put this in drivers/net/wireguard/generated/netlink.{c.h}
>     And then in the Makefile, do `wireguard-y += netlink.o generated/netlink.o`
>     on one line like that. I prefer this to keeping it in the same
>     directory with the awkward -gen suffix.

Sure, there isn't much consistency across families anyway.

Re: [PATCH net-next v3 00/11] wireguard: netlink: ynl conversion

[Jakub Kicinski]

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. 

Re: [PATCH net-next v3 00/11] wireguard: netlink: ynl conversion

[Jason A. Donenfeld]

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

Re: [PATCH net-next v3 00/11] wireguard: netlink: ynl conversion

[Jakub Kicinski]

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

Re: [PATCH net-next v3 00/11] wireguard: netlink: ynl conversion

[Jason A. Donenfeld]

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

Re: [PATCH net-next v3 00/11] wireguard: netlink: ynl conversion

[Jakub Kicinski]

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