From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 65781257845 for ; Tue, 17 Mar 2026 15:47:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773762470; cv=none; b=KpXrTGk2jAAP7OvDUm7XWG/dw6ghX0eYBKyGzi+5/w08XUIDuc9qdMJ6rEUt1HUxJNOEpLCErbM3yS5edkbsnO+wHKZw9iHHzDtK7l+OOo3iP2kJQwC1DJ3fuyCDUq56hT5+ex7NDWqzsJ19+7KEhDjodeQGrN7R3bPMzHv9qJU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773762470; c=relaxed/simple; bh=IjrsCxwkBJOYLk4aZ6wtP5PCepQhlJsiDOrbtIUG05c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=u5lmD1NcZoDSiLTq6ZKeKRYmKNzZWsXBxqYAhlaZVUzx4BMkoGAIdo4Lp88hMEZ8w2T8TWkNkH8FJECLsy0nBz3D8wesRJETSIubQ/HKm7eeJ2KzRHlreKrN+jW3UDREgrlcj/6OOahPjhW5vDR9o7/O51EpDdWU3fUypUmmYWE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linbit.com; spf=pass smtp.mailfrom=linbit.com; dkim=pass (2048-bit key) header.d=linbit-com.20230601.gappssmtp.com header.i=@linbit-com.20230601.gappssmtp.com header.b=GOKgP+4a; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linbit.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linbit.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linbit-com.20230601.gappssmtp.com header.i=@linbit-com.20230601.gappssmtp.com header.b="GOKgP+4a" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-483487335c2so56513855e9.2 for ; Tue, 17 Mar 2026 08:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linbit-com.20230601.gappssmtp.com; s=20230601; t=1773762467; x=1774367267; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=BWTbSNP2WHzhEIrAEAxvT9LPjTJQPOi5iCIjuQ8jmQA=; b=GOKgP+4ai/XEdjAJTPYrQiwtoq5enJR2T09vveK+WC3ytUZXf7Js1+gQd9Jooyu5qy evfqED7ehLPqEv3N9JPZk0Lt/Kxebs/7yIIJG5DpE5ALpKXMpzwnNrypXr0Pb7PSw7Qd 09zQdJ92O+V0ohAaWJmr51azduIUtN2iVSyQ78DxPdIMRyWlbZGhpE46waxdxUtkPEIl cCZboJum1zu3Y62RGkiUihsU1rU+rdciTmoDbeERfPrXtRVdM+dgHtephzirAGRjab/l 6nJEoDQgD1f71//RPzLBXAJJFFs4BSM+F5k5YoQyRqZgHC6BOXw++luyRbgml6aZkF6K EuOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773762467; x=1774367267; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BWTbSNP2WHzhEIrAEAxvT9LPjTJQPOi5iCIjuQ8jmQA=; b=aEyUAdBheircEvBBin6sRjUKCU07JlASfFukVqXrAsocrATVSDnvH2YXYiYwgtjYa5 afSC+BfgsjaxA+Kbnt+NDygIJU/mZqGMGQMCjYAaaHU0Eat+VDvGckUCsVgC+381HL2d HXV+giE8sams8g6vz0xn/K/B6f3cluq906wGv88pcICeupN59HFHECZO0zPl9WXNf7EN NINMhB55VULtJek6GmiOE2S8BN/clw+TgQdalE8tvzYe0qgAk3HrNvrGyXA8g9cAqnJO B6OCh9q1ErIBnUgxuxFUVqXEI7I2jLTWAncUjeflza0SFdMnOEMpvtMaZ9/npXq/tneM W/Tw== X-Forwarded-Encrypted: i=1; AJvYcCVmig+haLctSiNRo9Se8Be3+apVlEEYR4EwuoBZqCxHsp8qXpfNISdFsVxN8F4K10kL2pM6PWCQcaVViG8=@vger.kernel.org X-Gm-Message-State: AOJu0YzB5FbMWx0B82oSIbYGvNJZpHojntpkJaC9Omk7vzTmBxB46nAk 6i+2QZPpdE0tJq88B8VlOGUy3sftdMGERXRe0/zSzNTlRTnEbEdJC5CueFiUOtn60SU= X-Gm-Gg: ATEYQzwG7NQq1fzacACQtM9bMk92OmoByEzE52hEmmA2Afus1srf6SK9NLAloFyWTv2 nC7j13hHoQZe1Jaq4MfJJBXZKquhe24V5wcz/D1x/e6svYy+jFtLK6XHmY48FU9PWVB0yDSF30C 79CWOT9T4Qhc1Zd8K+XLA24xjFKX5QiiCA/v6tQcQJwPpSXpSFnCjDGa5ETySbfNEvWsvHPDKSy Y4TscB8oyv9ImL7mFq2yltN5FHB11ZpeBM/9yMxnoLn3cMPbbe5rhadTS9qPT90sVF9wUW4dqPs uTmKsYRIhPlcEmMwfFvDDGKgsNFOsOmzGjx223KU+MEQ4BPWmAOaH/7hmDdiZ/C2CBWODy/+rgB D+0mKBb7wd4iC2/+eFOZoj+Rh4AKpvFox38TlRFDW8LS+j0+7GLoS7ULesoaoqFwyFi9HW2u2vO 8avs68GnNkFcVxkM7/A4Nj7eaRjmmg89T0UefoMGqG0I2Cw/UX3zdF+GGMVl6rsLzkd7UwaIiV0 sCMW70gihGz4Wc= X-Received: by 2002:a05:600c:8483:b0:485:3f72:3230 with SMTP id 5b1f17b1804b1-486f4430051mr276845e9.15.1773762466590; Tue, 17 Mar 2026 08:47:46 -0700 (PDT) Received: from [192.168.178.55] (h082218028181.host.wavenet.at. [82.218.28.181]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4856ea8fad1sm132412305e9.1.2026.03.17.08.47.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Mar 2026 08:47:45 -0700 (PDT) Message-ID: <085c9532-5440-4879-bcde-4d70c980c839@linbit.com> Date: Tue, 17 Mar 2026 16:47:44 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] genetlink: add multi-version family support for protocol negotiation To: Jakub Kicinski Cc: Philipp Reisner , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Alok Tiwari , Kees Cook , netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260316151507.3958299-2-christoph.boehmwalder@linbit.com> <20260316113736.1085a124@kernel.org> From: =?UTF-8?Q?Christoph_B=C3=B6hmwalder?= Content-Language: en-US In-Reply-To: <20260316113736.1085a124@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 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. Best Regards, Christoph -- Christoph Böhmwalder LINBIT | Keeping the Digital World Running DRBD HA — Disaster Recovery — Software defined Storage