[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200125184958.GA2993@unreal>
Date: Sat, 25 Jan 2020 20:49:58 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Michal Kubecek <mkubecek@...e.cz>,
Michal Kalderon <michal.kalderon@...vell.com>,
linux-netdev <netdev@...r.kernel.org>,
RDMA mailing list <linux-rdma@...r.kernel.org>
Subject: Re: [PATCH net-next v1] net/core: Replace driver version to be
kernel version
On Sat, Jan 25, 2020 at 08:55:01AM -0800, Florian Fainelli wrote:
>
>
> On 1/25/2020 8:14 AM, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@...lanox.com>
> >
> > In order to stop useless driver version bumps and unify output
> > presented by ethtool -i, let's overwrite the version string.
> >
> > Before this change:
> > [leonro@...er ~]$ ethtool -i eth0
> > driver: virtio_net
> > version: 1.0.0
> > After this change:
> > [leonro@...ver ~]$ ethtool -i eth0
> > driver: virtio_net
> > version: 5.5.0-rc6+
> >
> > Signed-off-by: Leon Romanovsky <leonro@...lanox.com>> ---
> > Changelog:
> > v1: Resend per-Dave's request
> > https://lore.kernel.org/linux-rdma/20200125.101311.1924780619716720495.davem@davemloft.net
> > No changes at all and applied cleanly on top of "3333e50b64fe Merge branch 'mlxsw-Offload-TBF'"
> > v0: https://lore.kernel.org/linux-rdma/20200123130541.30473-1-leon@kernel.org
>
> There does not appear to be any explanation why we think this is a good
> idea for *all* drivers, and not just the ones that are purely virtual?
We beat this dead horse too many times already, latest discussion and
justification can be found in that thread.
https://lore.kernel.org/linux-rdma/20200122152627.14903-1-michal.kalderon@marvell.com/T/#md460ff8f976c532a89d6860411c3c50bb811038b
However, it was discussed in ksummit mailing list too and overall
agreement that version exposed by in-tree modules are useless and
sometimes even worse. They mislead users to expect some features
or lack of them based on this arbitrary string.
>
> Are you not concerned that this is ABI and that specific userland may be
> relying on a specific info format and we could now be breaking their
> version checks? I do not disagree that the version is not particularly
> useful for in-tree kernel, but this is ABI, and breaking user-space is
> usually a source of support questions.
See this Linus's response:
"The unified policy is pretty much that version codes do not matter, do
not exist, and do not get updated.
Things are supposed to be backwards and forwards compatible, because
we don't accept breakage in user space anyway. So versioning is
pointless, and only causes problems."
https://lore.kernel.org/ksummit-discuss/CA+55aFx9A=5cc0QZ7CySC4F2K7eYaEfzkdYEc9JaNgCcV25=rg@mail.gmail.com/
I also don't think that declaring every print in the kernel as ABI is
good thing to do. We are not breaking binary ABI and continuing to
supply some sort of versioning, but in unified format and not in wild
west way like it is now.
So bottom line, if some REAL user space application (not test suites) relies
on specific version reported from ethtool, it is already broken and can't work
sanely for stable@, distros and upstream kernels.
Thanks
Powered by blists - more mailing lists