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

["Christoph Böhmwalder" <christoph.boehmwalder@linbit.com>]

Am 17.03.26 um 23:17 schrieb Jakub Kicinski:
> 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).

We are actually working on exactly that as part of our upstreaming
efforts (implementing YNL-based generation of the genl headers for
DRBD). So the macro magic will be removed soon.

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

The new family indeed sounds like a way out. So we would register two
families: the old "drbd" for the compat case, and a new "drbd2" with the
new command set. Would that be more in line with the "standard approach"?

Thanks,
Christoph

-- 
Christoph Böhmwalder
LINBIT | Keeping the Digital World Running
DRBD HA —  Disaster Recovery — Software defined Storage