From kuba at kernel.org Wed Nov 5 03:07:56 2025 From: kuba at kernel.org (Jakub Kicinski) Date: Tue, 4 Nov 2025 19:07:56 -0800 Subject: [PATCH net-next v2 04/11] netlink: specs: add specification for wireguard In-Reply-To: <20251031160539.1701943-5-ast@fiberby.net> References: <20251031160539.1701943-1-ast@fiberby.net> <20251031160539.1701943-5-ast@fiberby.net> Message-ID: <20251104190756.3a69dc2b@kernel.org> On Fri, 31 Oct 2025 16:05:30 +0000 Asbj?rn Sloth T?nnesen wrote: > + name: flags > + doc: | > + ``0`` or ``WGDEVICE_F_REPLACE_PEERS`` if all current peers > + should be removed prior to adding the list below. > + type: u32 > + enum: wgdevice-flags > + checks: > + flags-mask: wgdevice-flags The checks: should not be necessary if the enum is specified and it is itself of type: flags. From kuba at kernel.org Wed Nov 5 03:08:41 2025 From: kuba at kernel.org (Jakub Kicinski) Date: Tue, 4 Nov 2025 19:08:41 -0800 Subject: [PATCH net-next v2 08/11] tools: ynl: add sample for wireguard In-Reply-To: <20251031160539.1701943-9-ast@fiberby.net> References: <20251031160539.1701943-1-ast@fiberby.net> <20251031160539.1701943-9-ast@fiberby.net> Message-ID: <20251104190841.4582e578@kernel.org> On Fri, 31 Oct 2025 16:05:34 +0000 Asbj?rn Sloth T?nnesen wrote: > +F: tools/include/uapi/linux/wireguard.h Please don't copy the headers. Add an entry in Makefile.deps instead. From kuba at kernel.org Tue Nov 11 02:07:46 2025 From: kuba at kernel.org (Jakub Kicinski) Date: Mon, 10 Nov 2025 18:07:46 -0800 Subject: [PATCH net-next v3 00/11] wireguard: netlink: ynl conversion In-Reply-To: <20251105183223.89913-1-ast@fiberby.net> References: <20251105183223.89913-1-ast@fiberby.net> Message-ID: <20251110180746.4074a9ca@kernel.org> 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. From Jason at zx2c4.com Wed Nov 12 03:59:30 2025 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 12 Nov 2025 04:59:30 +0100 Subject: [PATCH net-next v3 00/11] wireguard: netlink: ynl conversion In-Reply-To: <20251110180746.4074a9ca@kernel.org> References: <20251105183223.89913-1-ast@fiberby.net> <20251110180746.4074a9ca@kernel.org> Message-ID: 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