Message ID | 20230127102133.700173-2-sw@simonwunderlich.de (mailing list archive) |
---|---|
State | Not Applicable, archived |
Delegated to: | Simon Wunderlich |
Headers |
Return-Path: <b.a.t.m.a.n-bounces+patchwork=open-mesh.org@lists.open-mesh.org> X-Original-To: patchwork@open-mesh.org Delivered-To: patchwork@open-mesh.org Received: from diktynna.open-mesh.org (localhost [IPv6:::1]) by diktynna.open-mesh.org (Postfix) with ESMTP id 14CF784582 for <patchwork@open-mesh.org>; Fri, 27 Jan 2023 11:22:11 +0100 (CET) Received: from mail.simonwunderlich.de (mail.simonwunderlich.de [23.88.38.48]) by diktynna.open-mesh.org (Postfix) with ESMTPS id 883B7805AC for <b.a.t.m.a.n@lists.open-mesh.org>; Fri, 27 Jan 2023 11:21:36 +0100 (CET) ARC-Seal: i=2; s=20121; d=open-mesh.org; t=1674814896; a=rsa-sha256; cv=pass; b=SeoKcBdEl3tPLZAmA4sg8FUooWlsk3wXinxkDQnVo8lEM3F08BHbEHgeX71Z6GJ7FZm8cX 4NtIVmwvEyT1BnDkTy5s9gfRaXNBs7xMXD+bvCm83dkQhCq2sZss0/wDLVGckt1m0YgcFP NHhPJ2cv6AZUsRLWR5Z8jpd4Cvb38gY= ARC-Authentication-Results: i=2; diktynna.open-mesh.org; dkim=pass header.d=simonwunderlich.de header.s=09092022 header.b=KSmKO++k; spf=pass (diktynna.open-mesh.org: domain of sw@simonwunderlich.de designates 23.88.38.48 as permitted sender) smtp.mailfrom=sw@simonwunderlich.de; arc=pass ("simonwunderlich.de:s=09092022:i=1"); dmarc=pass (policy=none) header.from=simonwunderlich.de ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=open-mesh.org; s=20121; t=1674814896; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ZvLElpC1+VVIp39vMIrU5LoBRiGr9pejs0Xce5d2JTM=; b=N/v6SJC52ohq7z16QcDrJkw8i0p5BDU+Ja1Rdh+Nwbec1TOtbcBPyQVAcOs2QgEgS3VZx4 ULmdcjtTacf+qo+aYn5gDxTTAJVQnZBbIrgrQrCl9sd6DIXEX4LMOtNbFq64GDg+Q06q7z WGoOOKQHgC12/8FG8tXNgph0pzjXGDU= Received: from kero.packetmixer.de (p200300C5973eAed8832E80845Eb11f67.dip0.t-ipconnect.de [IPv6:2003:c5:973e:aed8:832e:8084:5eb1:1f67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.simonwunderlich.de (Postfix) with ESMTPSA id 47F4BFAFDB; Fri, 27 Jan 2023 11:21:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=simonwunderlich.de; s=09092022; t=1674814896; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZvLElpC1+VVIp39vMIrU5LoBRiGr9pejs0Xce5d2JTM=; b=KSmKO++kKswmJO78DSO8+r8aVxek2gnRKgl/iR0kjWK5y8um1b5rJhTw1y99rQtE4H0Z5r F2k7H+ssOHPXeI7oqiBgq77oibi+Xjrp+oc/CyVN2hiA9wGm13f5V1KZSdEjAOqZ4rMs7/ rktMHyBstl4gvS5G6sKpVXp6tdmBULea7T6HAD0Jy2DyHvHza0oxIX9l2Naw6dlAsK9d3i lYiczDZjdI6JPkV9scRPLMaNudAqYs6s7bxd4GRQb4OUAk5z6iIxweFyOX6Ixw+zsnjG8a GR/aMveYWp6cBJzYCOllP+A5o2DdoaEXOPAqSa9bf9MLe5GF4uQz34WHzPFaPg== From: Simon Wunderlich <sw@simonwunderlich.de> To: kuba@kernel.org, davem@davemloft.net Subject: [PATCH 1/5] batman-adv: Start new development cycle Date: Fri, 27 Jan 2023 11:21:29 +0100 Message-Id: <20230127102133.700173-2-sw@simonwunderlich.de> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20230127102133.700173-1-sw@simonwunderlich.de> References: <20230127102133.700173-1-sw@simonwunderlich.de> MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=simonwunderlich.de; s=09092022; t=1674814896; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZvLElpC1+VVIp39vMIrU5LoBRiGr9pejs0Xce5d2JTM=; b=c9Dz2OLpNFukMVRawYs0TLlrEBCYdxuK0xrfkMazVNQFu3Roaplj/QZ6HKuRpGY27C/ZhX u3VGJPh2DrJQRegsWai9yIacuauLPj36Wg7p1ClCipasVrDfACKRKgHxfbhrbv93erkEDg Yvuotj0AKwPE/+WR/DQVDn/5Crv7CZhxMDTfYXiZkxE+3InWJLk+i2WakKeovFR5jMpMg4 Cv2onBPUHCOmUZnAjB32T56Zbi0Xe5XlYmolWy0OyvDb4PYiXIaWndShnKjK29RG9MAfDz o18LNdlJEdo1Aoh8LCOBimV7zW8F5InmLSqLzmiVOQ0fJL6jIe/eQdpWyHeycg== ARC-Seal: i=1; s=09092022; d=simonwunderlich.de; t=1674814896; a=rsa-sha256; cv=none; b=wUr3t+U0wzKru1ENhK+ueeEPwZyPCiAN3lbRHzYx+3Q0bEDoAimUPsInHOjmbXQqT61RNnnfiH1PRlPNxnuEioMGqugCVPfcdVv0qOU9tHxbDF7FomK8Aq8XaTvXy72uNl2MXp4GsECJ4olWKGBgcn/XmPwAbbhpjL8euODpJcYC577TfUrGFeRHw8O1Oy4AlzQ1MSz2gx4cRDw1sqTAps5sbj1fhfxXKvks4Mxhc0brPGF9jiC2NTz0mcpXqScOWtdpoSF2iyHCWXL6zshsDbWYhntqZ2ogo2CzszZFg3tZoEq/yPD0SjYy5Q6RwMxdGpxATccPVmK+/FwF5mmrrw== ARC-Authentication-Results: i=1; mail.simonwunderlich.de; auth=pass smtp.auth=sw@simonwunderlich.de smtp.mailfrom=sw@simonwunderlich.de Content-Transfer-Encoding: quoted-printable Message-ID-Hash: AK2BBEY544DFREP5P6X54NAH4IB53R7Q X-Message-ID-Hash: AK2BBEY544DFREP5P6X54NAH4IB53R7Q X-MailFrom: sw@simonwunderlich.de X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-b.a.t.m.a.n.lists.open-mesh.org-0; header-match-b.a.t.m.a.n.lists.open-mesh.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: netdev@vger.kernel.org, b.a.t.m.a.n@lists.open-mesh.org X-Mailman-Version: 3.2.1 Precedence: list List-Id: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n.lists.open-mesh.org> Archived-At: <https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/message/AK2BBEY544DFREP5P6X54NAH4IB53R7Q/> List-Archive: <https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/> List-Help: <mailto:b.a.t.m.a.n-request@lists.open-mesh.org?subject=help> List-Post: <mailto:b.a.t.m.a.n@lists.open-mesh.org> List-Subscribe: <mailto:b.a.t.m.a.n-join@lists.open-mesh.org> List-Unsubscribe: <mailto:b.a.t.m.a.n-leave@lists.open-mesh.org> |
Series | [1/5] batman-adv: Start new development cycle | |
Commit Message
Simon Wunderlich
Jan. 27, 2023, 10:21 a.m. UTC
This version will contain all the (major or even only minor) changes for
Linux 6.3.
The version number isn't a semantic version number with major and minor
information. It is just encoding the year of the expected publishing as
Linux -rc1 and the number of published versions this year (starting at 0).
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
---
net/batman-adv/main.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Hello: This series was applied to netdev/net-next.git (master) by Simon Wunderlich <sw@simonwunderlich.de>: On Fri, 27 Jan 2023 11:21:29 +0100 you wrote: > This version will contain all the (major or even only minor) changes for > Linux 6.3. > > The version number isn't a semantic version number with major and minor > information. It is just encoding the year of the expected publishing as > Linux -rc1 and the number of published versions this year (starting at 0). > > [...] Here is the summary with links: - [1/5] batman-adv: Start new development cycle https://git.kernel.org/netdev/net-next/c/55307f51f48e - [2/5] batman-adv: Drop prandom.h includes https://git.kernel.org/netdev/net-next/c/c4b40f80585c - [3/5] batman-adv: Fix mailing list address https://git.kernel.org/netdev/net-next/c/8f6bc4583713 - [4/5] batman-adv: mcast: remove now redundant single ucast forwarding https://git.kernel.org/netdev/net-next/c/e7d6127b89a9 - [5/5] batman-adv: tvlv: prepare for tvlv enabled multicast packet type https://git.kernel.org/netdev/net-next/c/0c4061c0d0e2 You are awesome, thank you!
Fri, Jan 27, 2023 at 11:21:29AM CET, sw@simonwunderlich.de wrote: >This version will contain all the (major or even only minor) changes for >Linux 6.3. > >The version number isn't a semantic version number with major and minor >information. It is just encoding the year of the expected publishing as >Linux -rc1 and the number of published versions this year (starting at 0). I wonder, what is this versioning good for?
On Mon, Jan 30, 2023 at 03:55:08PM +0100, Jiri Pirko wrote: > Fri, Jan 27, 2023 at 11:21:29AM CET, sw@simonwunderlich.de wrote: > >This version will contain all the (major or even only minor) changes for > >Linux 6.3. > > > >The version number isn't a semantic version number with major and minor > >information. It is just encoding the year of the expected publishing as > >Linux -rc1 and the number of published versions this year (starting at 0). > > I wonder, what is this versioning good for? The best reason in my opinion is that it's useful to convince ordinary people that they should update :-). Usually when debugging reported issues one of the first things we ask users is to provide the output of "batctl -v": ``` $ batctl -v batctl debian-2023.0-1 [batman-adv: 2022.3] ``` If there is a very old year in there I think it's easier to tell and convince people to try again with newer versions and to update. And also as a developer I find it easier to (roughly) memorize when a feature was added by year than by kernel version number. So I know by heart that TVLVs were added in 2014 and multicast snooping patches and new multicast handling was added around 2019 for instance. But don't ask me which kernel version that was :D. I'd have to look that up. So if "batctl -v" displayed a kernel version number that would be less helpful for me. Also makes it easier for ordinary users to look up and compare their version with our news archive: https://www.open-mesh.org/projects/open-mesh/wiki/News-archive Also note that we can't do a simple kernel version to year notation mapping in userspace in batctl. OpenWrt uses the most recent Linux LTS release. But might feature a backport of a more recent batman-adv which is newer than the one this stable kernel would provide. Or people also often use Debian stable but compile and use the latest batman-adv version with it. Does that make sense?
Thu, Feb 02, 2023 at 07:44:06PM CET, linus.luessing@c0d3.blue wrote: >On Mon, Jan 30, 2023 at 03:55:08PM +0100, Jiri Pirko wrote: >> Fri, Jan 27, 2023 at 11:21:29AM CET, sw@simonwunderlich.de wrote: >> >This version will contain all the (major or even only minor) changes for >> >Linux 6.3. >> > >> >The version number isn't a semantic version number with major and minor >> >information. It is just encoding the year of the expected publishing as >> >Linux -rc1 and the number of published versions this year (starting at 0). >> >> I wonder, what is this versioning good for? > >The best reason in my opinion is that it's useful to convince >ordinary people that they should update :-). > >Usually when debugging reported issues one of the first things we ask >users is to provide the output of "batctl -v": > >``` >$ batctl -v >batctl debian-2023.0-1 [batman-adv: 2022.3] Why kernel version is not enough for you? My point is, why to maintain internal driver version alongside with the kernel version? I just don't see any point of having these parallel driver versions. Looks like a historical relict. IDK. I'w just wondering, that's all. >``` > >If there is a very old year in there I think it's easier to tell >and convince people to try again with newer versions and to >update. > >And also as a developer I find it easier to (roughly) memorize >when a feature was added by year than by kernel version number. >So I know by heart that TVLVs were added in 2014 and multicast >snooping patches and new multicast handling was added around 2019 >for instance. But don't ask me which kernel version that was :D. >I'd have to look that up. So if "batctl -v" displayed a kernel >version number that would be less helpful for me. > >Also makes it easier for ordinary users to look up and >compare their version with our news archive: >https://www.open-mesh.org/projects/open-mesh/wiki/News-archive > >Also note that we can't do a simple kernel version to year >notation mapping in userspace in batctl. OpenWrt uses the most >recent Linux LTS release. But might feature a backport of a more >recent batman-adv which is newer than the one this stable kernel >would provide. Or people also often use Debian stable but compile >and use the latest batman-adv version with it. Yeah, for out of tree driver, have whatever. > >Does that make sense?
On Friday, 3 February 2023 09:29:50 CET Jiri Pirko wrote: [...] > Why kernel version is not enough for you? My point is, why to maintain > internal driver version alongside with the kernel version? [...] > >Also note that we can't do a simple kernel version to year > >notation mapping in userspace in batctl. OpenWrt uses the most > >recent Linux LTS release. But might feature a backport of a more > >recent batman-adv which is newer than the one this stable kernel > >would provide. Or people also often use Debian stable but compile > >and use the latest batman-adv version with it. > > Yeah, for out of tree driver, have whatever. A while back, my personal opinion changed after there were various Linux developers/maintainers were trying to either remove it or wondering about this bump. The idea which I've proposed was to: * still ship the "backports" like out-of-tree tarball with a module version - but directly in its "compat" code * continue to use in projects (which for whatever reason cannot use the in- kernel implementation) a version which represents their upstream backports tarball + their (patch) revision: Something like "2022.0-openwrt-7" * for the in-kernel module, just return either - remove the version information completely from the kernel module MODULE_VERSION + drop BATADV_ATTR_VERSION + modifying batctl to fetch that from uname(). But of course, that would break old batctl versions [1] - or by setting BATADV_SOURCE_VERSION to UTS_RELEASE (+suffix?) or UTS_VERSION But this wasn't well received when mentioning it to Simon+Linus (but I could misremember the persons involved here). Kind regards, Sven [1] https://lore.kernel.org/r/20201205085604.1e3fcaee@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com
On Fri, Feb 03, 2023 at 10:38:07AM +0100, Sven Eckelmann wrote: > On Friday, 3 February 2023 09:29:50 CET Jiri Pirko wrote: > [...] > > Why kernel version is not enough for you? My point is, why to maintain > > internal driver version alongside with the kernel version? > [...] > > >Also note that we can't do a simple kernel version to year > > >notation mapping in userspace in batctl. OpenWrt uses the most > > >recent Linux LTS release. But might feature a backport of a more > > >recent batman-adv which is newer than the one this stable kernel > > >would provide. Or people also often use Debian stable but compile > > >and use the latest batman-adv version with it. > > > > Yeah, for out of tree driver, have whatever. > > A while back, my personal opinion changed after there were various Linux > developers/maintainers were trying to either remove it or wondering about this > bump. The idea which I've proposed was to: > > * still ship the "backports" like out-of-tree tarball with a module version - > but directly in its "compat" code > * continue to use in projects (which for whatever reason cannot use the in- > kernel implementation) a version which represents their upstream backports > tarball + their (patch) revision: Something like "2022.0-openwrt-7" > * for the in-kernel module, just return either > > - remove the version information completely from the kernel module > MODULE_VERSION + drop BATADV_ATTR_VERSION + modifying batctl to fetch that > from uname(). But of course, that would break old batctl versions [1] > - or by setting BATADV_SOURCE_VERSION to UTS_RELEASE (+suffix?) or > UTS_VERSION > > > But this wasn't well received when mentioning it to Simon+Linus (but I could > misremember the persons involved here). In cases where you can prove real userspace breakage, we simply stop to update module versions. Thanks > > Kind regards, > Sven > > [1] https://lore.kernel.org/r/20201205085604.1e3fcaee@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com
On Tuesday, 7 February 2023 10:02:58 CET Leon Romanovsky wrote: > In cases where you can prove real userspace breakage, we simply stop to > update module versions. That would be the worst option. Then the kernel shows bogus values and no one is helped. And how should I prove it to you? Is that enough? $ lsmod|grep '^batman_adv' batman_adv 266240 0 $ sudo batctl -v batctl debian-2022.3-2 [batman-adv: module not loaded] $ sudo batctl if add enp70s0 Error - batman-adv module has not been loaded $ sudo ip link show dev bat0 8: bat0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 7a:8b:21:b7:13:b8 brd ff:ff:ff:ff:ff:ff $ sudo ip link set master bat0 dev enp70s0 $ sudo ip link set up dev bat0 $ sudo batctl n Missing attributes from kernel $ sudo batctl o Missing attributes from kernel Expected was following output: $ sudo batctl -v batctl debian-2022.3-2 [batman-adv: 2022.3] $ sudo batctl if add enp70s0 $ sudo ip link show dev bat0 $ sudo ip link set up dev bat0 $ sudo batctl n [B.A.T.M.A.N. adv 2022.3, MainIF/MAC: enp70s0/2c:f0:5d:04:70:39 (bat0/7a:8b:21:b7:13:b8 BATMAN_IV)] IF Neighbor last-seen enp70s0 50:7b:9d:ce:26:83 0.708s $ sudo batctl o [B.A.T.M.A.N. adv 2022.3, MainIF/MAC: enp70s0/2c:f0:5d:04:70:39 (bat0/7a:8b:21:b7:13:b8 BATMAN_IV)] Originator last-seen (#/255) Nexthop [outgoingIF] * 50:7b:9d:ce:26:83 0.684s (255) 50:7b:9d:ce:26:83 [ enp70s0] Kind regards, Sven
On Tue, Feb 07, 2023 at 10:50:08AM +0100, Sven Eckelmann wrote: > On Tuesday, 7 February 2023 10:02:58 CET Leon Romanovsky wrote: > > In cases where you can prove real userspace breakage, we simply stop to > > update module versions. > > That would be the worst option. Then the kernel shows bogus values and no one > is helped. The thing is that you already show bogus values. Most users don't compile their kernel, but use distro-based one. The latter is a mix of base kernel, fixes and sometimes backports. For example, on my system: ➜ kernel git:(wip/leon-for-next) modinfo batman_adv filename: /lib/modules/6.1.9-200.fc37.x86_64/kernel/net/batman-adv/batman-adv.ko.xz .... version: 2022.3 description: B.A.T.M.A.N. advanced ... name: batman_adv vermagic: 6.1.9-200.fc37.x86_64 SMP preempt mod_unload As you can see both of us have 2022.3 in version string, but are we running same code? The answer is no as you run debian and I'm running latest Fedora with different kernel version, which means different batman_adv feature set. Once you stop to update version, you will push users to look on the real version (kernel) which really matters. Thanks > > > And how should I prove it to you? Is that enough? > > $ lsmod|grep '^batman_adv' > batman_adv 266240 0 > $ sudo batctl -v > batctl debian-2022.3-2 [batman-adv: module not loaded] > $ sudo batctl if add enp70s0 > Error - batman-adv module has not been loaded > $ sudo ip link show dev bat0 > 8: bat0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 > link/ether 7a:8b:21:b7:13:b8 brd ff:ff:ff:ff:ff:ff > $ sudo ip link set master bat0 dev enp70s0 > $ sudo ip link set up dev bat0 > $ sudo batctl n > Missing attributes from kernel > $ sudo batctl o > Missing attributes from kernel > > > Expected was following output: > > $ sudo batctl -v > batctl debian-2022.3-2 [batman-adv: 2022.3] > $ sudo batctl if add enp70s0 > $ sudo ip link show dev bat0 > $ sudo ip link set up dev bat0 > $ sudo batctl n > [B.A.T.M.A.N. adv 2022.3, MainIF/MAC: enp70s0/2c:f0:5d:04:70:39 (bat0/7a:8b:21:b7:13:b8 BATMAN_IV)] > IF Neighbor last-seen > enp70s0 50:7b:9d:ce:26:83 0.708s > $ sudo batctl o > [B.A.T.M.A.N. adv 2022.3, MainIF/MAC: enp70s0/2c:f0:5d:04:70:39 (bat0/7a:8b:21:b7:13:b8 BATMAN_IV)] > Originator last-seen (#/255) Nexthop [outgoingIF] > * 50:7b:9d:ce:26:83 0.684s (255) 50:7b:9d:ce:26:83 [ enp70s0] > > Kind regards, > Sven
On Tuesday, 7 February 2023 11:41:53 CET Leon Romanovsky wrote: > Once you stop to update version, you will push users to look on the real > version (kernel) which really matters. I would have understood if you say "let us use a magic value like 'in-tree' or 'linux'" but setting it to an old (existing) version number - I don't want to live with the headaches it creates. Because this is what users often don't (want) to understand: if it looks like a valid version number, why isn't it the valid version number? So I have to do a lot of pushing - without any rewards because it is necessary to push every new "user". Kind regards, Sven
On Tue, Feb 07, 2023 at 11:57:41AM +0100, Sven Eckelmann wrote: > On Tuesday, 7 February 2023 11:41:53 CET Leon Romanovsky wrote: > > Once you stop to update version, you will push users to look on the real > > version (kernel) which really matters. > > I would have understood if you say "let us use a magic value like 'in-tree' or > 'linux'" but setting it to an old (existing) version number - I don't want to > live with the headaches it creates. Because this is what users often don't > (want) to understand: if it looks like a valid version number, why isn't it > the valid version number? So I have to do a lot of pushing - without any > rewards because it is necessary to push every new "user". I'm not sharing your view about users and think they need to be educated, even it is hard and non-rewarding job. Thanks > > Kind regards, > Sven
diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h index c48803b32bb0..156ed39eded1 100644 --- a/net/batman-adv/main.h +++ b/net/batman-adv/main.h @@ -13,7 +13,7 @@ #define BATADV_DRIVER_DEVICE "batman-adv" #ifndef BATADV_SOURCE_VERSION -#define BATADV_SOURCE_VERSION "2022.3" +#define BATADV_SOURCE_VERSION "2023.1" #endif /* B.A.T.M.A.N. parameters */