From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (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 58B5D27603A for ; Wed, 18 Mar 2026 14:54:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773845650; cv=none; b=D0G/pkX/Ek9W2en68JOfmSKf/eRTVJ1Vo0lFyq/Cx4YlMEdDT+/MNDNZ0KY3NkceKHt4B245Tq7QAL0bMGnoRbgK2uc89Qq8n5qEuvoEsuCcJmIKY8ZX2unHX7M27heNOHyXgs0LLg9ZEoq4myuLiraap2WwXSUjL+F1Uw0gpoQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773845650; c=relaxed/simple; bh=phrZMY/iUGqX9FbeAjQ9S4m4uoKH9/LsPe1PYJCUU9c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mGU0aYbqQC6dMvtBOesnzE5UU8N/YUyWWYCVrAXvoNdMqglkO7sodIi1bcYqreYLC4q7DQ9bKVdnuvHe0dols4gzGXvCKOofFFUnFr7VHeuGLy5/O2gq3T1g+lE//3bmCnMJTiQdMJR0W8K53AzDcqXxpbCeLUAtQ/mWTOfuwYs= 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=Uph/m+Jb; arc=none smtp.client-ip=209.85.128.48 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="Uph/m+Jb" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-48540d21f7dso78200715e9.0 for ; Wed, 18 Mar 2026 07:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linbit-com.20230601.gappssmtp.com; s=20230601; t=1773845647; x=1774450447; 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=yzi5TLVbzrwenc6vxPwdtQ+F2R3dH5U7IECzTFPhoOY=; b=Uph/m+Jb3NH0S4u2hSfy09FB4lDmRb3NDhHMiZnTIRk8KthWlVXRS18o/OS2AnzmaB UAAh8u1k8xdUYYtVOlPs6MBXesSG3buI9WgbQ3BDpEERrizme0r9R8YVmnv+HX1OgAcC cH+H1BGPPYXeJZkZPAhC6Tine66EOPdwrJtgoPeK0Gg4ZTzCgc8XNlMGo+gV4+pZUtdj R8M3sViUu8OyAAAMrZgbm6XWWuW/OYkKo3LQSTEbUaWVYp4z58QxHrVZsDp2m/M7igBQ /3DEc1puubz04uGDE7UzzacKOc0imF8dERizigc3OfXgHDZyh13kpEtsXwRWM+sN3ezv xrcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773845647; x=1774450447; 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=yzi5TLVbzrwenc6vxPwdtQ+F2R3dH5U7IECzTFPhoOY=; b=Zqs8DVvUP6CZc5gS9usXg7dbDYaIqBoIGzK9Lkg+c/MEACPHof0WjEgoKZGM4yN7QA zJOCLhBMnFQzGHj8ITR5vhktNwkKMuzpM37ECsb/iG8IXwwg0y/GNvBdxOAiVC5ti3PG PFcQt3N6nkoWP3QrGQQ4EYrYbtAfuz8SI0vNRhBvT2KxpfnPyfVxAkFayFiU9z1n7FCt nZm3W2T/qI2F4SeLKzHNsUxKwKAnOsNGBrMy38zinwIIEdIr2VfO5XEqCszc5IUF/Iv+ SnhkkyBXCbNHouca7tdYrNL3ga1W/upL4zu0gqw4MlCW92zIoE+DNyd2GMabWZf0vG+a wLYg== X-Forwarded-Encrypted: i=1; AJvYcCW/P9ilHcqlznzsUTTnWvw10uV4jEoPqQWGfmPyShOTBF04dxzs4t8oOdDr5jIIOoier7Wc/qoQkGIl25g=@vger.kernel.org X-Gm-Message-State: AOJu0Yy1wIXrfV74N8630xPNEHIqKEGoZoMx00cIVNNkNWVC6kAdEEK4 RUjF+e2A98F+YhfdNyzPVJhzXu/n6E6eAPTb7mboqh7JTxq4p+dD5biHxJYuElfQFN4= X-Gm-Gg: ATEYQzw+g7qSaYgNbA2jUkeJtPJCR/RwkQb3BgKiGM30Gu4a6Hg40WAugkzU+1iQw01 4kfx5NBu33TNJiAgYvlkmnwB+HoJnNBohJ8SveCQBQ2kCqWK6NzZY56ldacWz4Anzxt23yBOaKd F4QMTvrGGH9pDb4VtyKVc0DWulRnqEx09vhDERZVXUEfhE66KiOeBL/uzSRBrmOGfmeanbY8XmY h1jW/7vYqZoCPXNmK/sVMoTrnvqIf4p6T258gXFcXF3jcLLUEpmCBbWLBm6oSnYh7n5gu6xZQ9c mdXDnjlnaOvsR1WNjZdz//VaPFn1+yWOq1YT0DJSx7iJph79/dh6f5Jqiu2/VQrirAlxUHZJZEr Q2c47ZbdBXusQO/iEMLuG6gDYpwlV41jd/iLvSLRZazrpKENGbZC7zGan6YP22eKZit1SYZzWKG V54ia0JxJ7Ih509s2/yJtZO5gEwARnKMfZr9Q8fZZknJ/P4y0Wz4/dz961nuwFTNMQggCW5rc1A QQ8V5QEfsDZypU= X-Received: by 2002:adf:ec4d:0:b0:43b:54c9:7d25 with SMTP id ffacd0b85a97d-43b54c986e9mr2949187f8f.38.1773845646415; Wed, 18 Mar 2026 07:54:06 -0700 (PDT) Received: from [192.168.178.55] (h082218028181.host.wavenet.at. [82.218.28.181]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b51852ab3sm8733045f8f.12.2026.03.18.07.54.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Mar 2026 07:54:05 -0700 (PDT) Message-ID: Date: Wed, 18 Mar 2026 15:54:04 +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> <085c9532-5440-4879-bcde-4d70c980c839@linbit.com> <20260317151745.4562eefc@kernel.org> From: =?UTF-8?Q?Christoph_B=C3=B6hmwalder?= Content-Language: en-US In-Reply-To: <20260317151745.4562eefc@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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