From: Leon Romanovsky <email@example.com> To: Jakub Kicinski <firstname.lastname@example.org> Cc: Shannon Nelson <email@example.com>, "David S . Miller" <firstname.lastname@example.org>, Michal Kalderon <email@example.com>, linux-netdev <firstname.lastname@example.org>, RDMA mailing list <email@example.com> Subject: Re: [PATCH net-next] net/core: Replace driver version to be kernel version Date: Sun, 26 Jan 2020 23:08:50 +0200 [thread overview] Message-ID: <20200126210850.GB3870@unreal> (raw) In-Reply-To: <20200126124957.78a31463@cakuba> On Sun, Jan 26, 2020 at 12:49:57PM -0800, Jakub Kicinski wrote: > 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). Jakub, Shannon proposed to remove this field and it was me who said no :) My plan is to overwrite ->version, delete all users and add WARN_ONEC(strcpy(..->version_)...) inside net/ethtool/ to catch abusers. > > 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 I was inspired by upstream code. https://elixir.bootlin.com/linux/v5.5-rc7/source/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c#L184 > > > 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. The long-standing policy in kernel that we don't really care about out-of-tree code. Thanks
next prev parent reply other threads:[~2020-01-26 21:08 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-23 13:05 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 2020-01-26 21:08 ` Leon Romanovsky [this message] 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=20200126210850.GB3870@unreal \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH net-next] net/core: Replace driver version to be kernel version' \ /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
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).