From: Michal Kubecek <firstname.lastname@example.org> To: email@example.com Cc: Shannon Nelson <firstname.lastname@example.org>, Leon Romanovsky <email@example.com>, Jakub Kicinski <firstname.lastname@example.org>, "David S . Miller" <email@example.com>, Michal Kalderon <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: Mon, 27 Jan 2020 07:08:35 +0100 [thread overview] Message-ID: <20200127060835.GA570@unicorn.suse.cz> (raw) In-Reply-To: <firstname.lastname@example.org> On Sun, Jan 26, 2020 at 02:57:21PM -0800, Shannon Nelson wrote: > On 1/26/20 2:22 PM, Michal Kubecek wrote: > > On Sun, Jan 26, 2020 at 02:12:38PM -0800, Shannon Nelson wrote: > > > Part of the pain of supporting our users is getting them to give us useful > > > information about their problem. The more commands I need them to run to > > > get information about the environment, the less likely I will get anything > > > useful. We've been training our users over the years to use "ethtool -i" to > > > get a good chunk of that info, with the knowledge that the driver version is > > > only a hint, based upon the distro involved. I don't want to lose that > > > hint. If anything, I'd prefer that we added a field for UTS_RELEASE in the > > > ethtool output, but I know that's too much to ask. > > > > At the same time, I've been trying to explain both our L1/L2 support > > guys and our customers that "driver version" information reported by > > "ethtool -i" is almost useless and that if they really want to identify > > driver version, they should rather use srcversion as reported by modinfo > > or sysfs. > > So as I suggested elsewhere, can we compromise by not bashing the driver > string in the caller stack, but require the in-kernel drivers to use a > particular macro that will put the kernel/git version into the string? This > allows out-of-tree drivers the option of overriding the version with some > other string that can be meaningful in any other given old or new distro > kernel. This should be easy to enforce mechanically with checkpatch, and > easy enough to do a sweeping coccinelle change on the existing drivers. Personally, I rather liked what Jakub suggested earlier: set ethtool_drvinfo::version to kernel version before ops->get_drvinfo() is called in ethtool_get_drvinfo() (and its netlink counterpart once we get some consensus about what information should be in the message), clean up in-tree drivers so that they don't touch it and add a coccinelle check so that we keep in-tree drivers compliant; this would allow out-of-tree drivers to overwrite ethtool_drvinfo::version with whatever they want. Michal
next prev parent reply other threads:[~2020-01-27 6: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 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 [this message] 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=20200127060835.GA570@unicorn.suse.cz \ --email@example.com \ --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).