Re: [RFC PATCH] genetlink: add multi-version family support for protocol negotiation

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 17 Mar 2026 16:47:44 +0100 Christoph Böhmwalder wrote:
> Am 16.03.26 um 19:37 schrieb Jakub Kicinski:
> > What's the delta between the families? Do you have any examples of 
> > the the version ends up being used?  
> 
> The main difference between DRBD 8 and 9 in general is that 8 only
> replicates to a single peer, while 9 has support for multiple peers.
> This also introduces major changes in the genl family. For example, the
> "connect" command works completely differently between the v1 and v2
> families.
> In v1, it takes all the net_conf parameters and immediately sets up the
> connection.
> In v2, you need a new_peer / new_path command first; the net_conf is
> passed to new_peer in this case. The connect command then only
> "activates" the connection.
> So the semantics are completely different.
> 
> Other commands (like "state_info") were removed entirely and split up
> into different commands.
> 
> The specific exact diff is available as part of our prototype DRBD 9
> branch (included in linux-next):
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/diff/include/linux/drbd_genl.h?id=11b8887a3efae2868037f2bd8dbbc68a8591f66c

This uAPI header wrapped in DRDB magic tells me nothing.

The macro wrapping that DRBD does never gained broader adoption and
should be considered deprecated. Please take a look at YNL and the YAML
specs. (I mean this as a nack).

> As for the usage: the plan is for drbd to register its family with
> min_version=1, max_version=2. Then we would dispatch the v2 commands
> normally, and the v1 commands through a thin compat layer.
> In the in-tree DRBD, the version is currently unused. In the (still
> out-of-tree) DRBD 9 though, we do check that the version is what we expect:
> https://github.com/LINBIT/drbd/blob/master/drbd/drbd_nl.c#L426
> 
> This would be replaced by the mentioned compat dispatch logic once we
> have in-kernel infrastructure for supporting multiple versions.

I still feel a little bit in the dark as to what you're doing but the
normal path for Netlink is to add new attributes and commands in a
backward-compat manner. In case of DRBD given how "special" the
existing code is we could probably start a new family using modern
constructs.