[1/5] batman-adv: Start new development cycle

  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(-)
  

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