linux-kernel - Re: [RFC net-next 00/14] wireguard: netlink: ynl conversion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <de8ecfb8-ca4d-4397-9d70-4fe789e706f5@fiberby.net>
Date: Wed, 17 Sep 2025 11:52:31 +0000
From: Asbjørn Sloth Tønnesen <ast@...erby.net>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Donald Hunter <donald.hunter@...il.com>,
 Simon Horman <horms@...nel.org>, Jacob Keller <jacob.e.keller@...el.com>,
 Andrew Lunn <andrew+netdev@...n.ch>, wireguard@...ts.zx2c4.com,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC net-next 00/14] wireguard: netlink: ynl conversion

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@...erby.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/