This series contains the wireguard changes needed to adopt
an YNL-based generated netlink code.

This RFC series is posted for reference, as it is referenced
from the current v1 series of ynl preparations, which has to
go in before this series can be submitted for net-next.

This series applies on top of this series:
https://lore.kernel.org/netdev/20250904-wg-ynl-prep@fiberby.net/

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

 Documentation/netlink/specs/wireguard.yaml | 289 +++++++++++++++++++++
 MAINTAINERS                                |   3 +
 drivers/net/wireguard/Makefile             |   1 +
 drivers/net/wireguard/netlink.c            |  73 ++----
 drivers/net/wireguard/netlink_gen.c        |  77 ++++++
 drivers/net/wireguard/netlink_gen.h        |  29 +++
 include/uapi/linux/wireguard.h             | 202 +++-----------
 tools/net/ynl/samples/.gitignore           |   1 +
 tools/net/ynl/samples/wireguard.c          | 104 ++++++++
 9 files changed, 559 insertions(+), 220 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

Hi Asbjorn,

On Fri, Sep 5, 2025 at 12:03 AM Asbjørn Sloth Tønnesen <ast@fiberby.net> wrote:
>
> This series contains the wireguard changes needed to adopt
> an YNL-based generated netlink code.
>
> This RFC series is posted for reference, as it is referenced
> from the current v1 series of ynl preparations, which has to
> go in before this series can be submitted for net-next.

I'm not actually convinced this makes anything better. It seems like
the code becomes more complicated and less obvious. What is the
benefit here? As is, I really don't like this direction.

Jason

On 9/16/25 3:51 PM, Jason A. Donenfeld wrote:
> On Fri, Sep 5, 2025 at 12:03 AM Asbjørn Sloth Tønnesen <ast@fiberby.net> wrote:
>>
>> This series contains the wireguard changes needed to adopt
>> an YNL-based generated netlink code.
>>
>> This RFC series is posted for reference, as it is referenced
>> from the current v1 series of ynl preparations, which has to
>> go in before this series can be submitted for net-next.
> 
> I'm not actually convinced this makes anything better. It seems like
> the code becomes more complicated and less obvious. What is the
> benefit here? As is, I really don't like this direction.

By adding an YNL spec, we lower the barrier for implementing and
using the protocol especially from non-C languages.

The specs are currently used for:
- Documentation generation [1].
- Optional UAPI header generation.
- Optional kernel netlink code generation.
- In-tree user-space clients:
   - Auto-generated C library code.
   - Optional sample program using above C library.
   - Python client - ./tools/net/ynl/pyynl/cli.py.

The generated kernel code is still committed in git,
and is thus protected from accidental changes.

When we can generate the UAPI from the spec., with only cosmetic
differences it proves that the spec is correct. Same goes for generating
the netlink policy generation.

I have split up adopting the generated UAPI and netlink code, over many
patches mostly to keep the diff readable, as the code moves would
otherwise become interlaced.

Including a sample program, makes it trivial to exercise the generated
C library.

This RFC is a bit more complicated, than v1 will be, as it includes an
alternative implementation for patch 4 in patch 12, I had hoped those
patches would have generated some comments. Right now it looks like,
they will both be squashed into patch 3 in v1.

I can also split this series up further, if you would prefer that.

[1] https://docs.kernel.org/networking/netlink_spec/