linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: Shannon Nelson <snelson@pensando.io>,
	"David S . Miller" <davem@davemloft.net>,
	Michal Kalderon <michal.kalderon@marvell.com>,
	linux-netdev <netdev@vger.kernel.org>,
	RDMA mailing list <linux-rdma@vger.kernel.org>
Subject: Re: [PATCH net-next] net/core: Replace driver version to be kernel version
Date: Sun, 26 Jan 2020 12:49:57 -0800	[thread overview]
Message-ID: <20200126124957.78a31463@cakuba> (raw)
In-Reply-To: <20200126194110.GA3870@unreal>

On Sun, 26 Jan 2020 21:41:10 +0200, Leon Romanovsky wrote:
> > This will end up affecting out-of-tree drivers as well, where it is useful
> > to know what the version number is, most especially since it is different
> > from what the kernel provided driver is.  How else are we to get this
> > information out to the user?  If this feature gets squashed, we'll end up
> > having to abuse some other mechanism so we can get the live information from
> > the driver, and probably each vendor will find a different way to sneak it
> > out, giving us more chaos than where we started.  At least the ethtool
> > version field is a known and consistent place for the version info.
> >
> > Of course, out-of-tree drivers are not first class citizens, so I probably
> > lose that argument as well.
> >
> > So if you are so all fired up about not allowing the drivers to report their
> > own version number, then why report anything at all? Maybe just report a
> > blank field.  As some have said, the uname info is already available else
> > where, why are we sticking it here?
> >
> > Personally, I think this is a rather arbitrary, heavy handed and unnecessary
> > slam on the drivers, and will make support more difficult in the long run.  
> 
> The thing is that leaving this field as empty, for sure will break all
> applications. I have a feeling that it can be close to 100% hit rate.
> So, kernel version was chosen as an option, because it is already
> successfully in use by at least two drivers (nfp and hns).

Shannon does have a point that out of tree drivers still make use of
this field. Perhaps it would be a more suitable first step to print the
kernel version as default and add a comment saying upstream modules
shouldn't overwrite it (perhaps one day CI can catch new violators).

The NFP reports the git hash of the driver source plus the string
"(oot)" for out-of-tree:

https://github.com/Netronome/nfp-drv-kmods/blob/master/src/Kbuild#L297
https://github.com/Netronome/nfp-drv-kmods/blob/master/src/Kbuild#L315

> Leaving to deal with driver version to vendors is not an option too,
> because they prove for more than once that they are not capable to
> define user visible interfaces. It comes due to their natural believe
> that their company is alone in the world and user visible interface
> should be suitable for them only.
> 
> It is already impossible for users to distinguish properly versions
> of different vendors, because they use arbitrary strings with some
> numbers.

That is true. But reporting the kernel version without even as much as
in-tree/out-of-tree indication makes the field entirely meaningless.

  reply	other threads:[~2020-01-26 20:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-23 13:05 [PATCH net-next] net/core: Replace driver version to be kernel version Leon Romanovsky
2020-01-23 14:40 ` Jakub Kicinski
2020-01-23 14:54   ` Leon Romanovsky
2020-01-23 15:17     ` Jakub Kicinski
2020-01-25  9:13 ` David Miller
2020-01-26 18:56 ` Shannon Nelson
2020-01-26 19:41   ` Leon Romanovsky
2020-01-26 20:49     ` Jakub Kicinski [this message]
2020-01-26 21:08       ` Leon Romanovsky
2020-01-26 21:17         ` Shannon Nelson
2020-01-26 21:24           ` Leon Romanovsky
2020-01-26 22:12             ` Shannon Nelson
2020-01-26 22:22               ` Michal Kubecek
2020-01-26 22:57                 ` Shannon Nelson
2020-01-27  6:08                   ` Michal Kubecek
2020-01-27  6:42                     ` Leon Romanovsky
2020-01-27  5:18                 ` Leon Romanovsky
2020-01-26 21:33         ` Jakub Kicinski
2020-01-26 22:21           ` Shannon Nelson
2020-01-27  5:34             ` Leon Romanovsky
2020-01-27  6:45               ` Leon Romanovsky
2020-01-27 14:21                 ` Jakub Kicinski
2020-01-27 15:39                   ` Leon Romanovsky
2020-01-27  5:49           ` Leon Romanovsky
2020-01-27 12:21             ` David Miller
2020-01-27 12:42               ` Leon Romanovsky
2020-01-27 12:47                 ` David Miller
2020-01-27 17:57             ` Shannon Nelson
2020-01-26 20:52     ` Shannon Nelson
2020-01-26 21:19       ` Leon Romanovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200126124957.78a31463@cakuba \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=michal.kalderon@marvell.com \
    --cc=netdev@vger.kernel.org \
    --cc=snelson@pensando.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).