From: Shannon Nelson <snelson@pensando.io>
To: Jakub Kicinski <kuba@kernel.org>, Leon Romanovsky <leon@kernel.org>
Cc: "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 14:21:58 -0800 [thread overview]
Message-ID: <2a8d0845-9e6d-30ab-03d9-44817a7c2848@pensando.io> (raw)
In-Reply-To: <20200126133353.77f5cb7e@cakuba>
On 1/26/20 1:33 PM, Jakub Kicinski wrote
>> The long-standing policy in kernel that we don't really care about
>> out-of-tree code.
> Yeah... we all know it's not that simple :)
>
> The in-tree driver versions are meaningless and cause annoying churn
> when people arbitrarily bump them. If we can get people to stop doing
> that we'll be happy, that's all there is to it.
>
Perhaps it would be helpful if this standard was applied to all the
drivers equally? For example, I see that this week's ice driver update
from Intel was accepted with no comment on their driver version bump.
Look, if we want to stamp all in-kernel drivers with the kernel version,
fine. But let's do it in a way that doesn't break the out-of-tree
driver ability to report something else. Can we set up a macro for
in-kernel drivers to use in their get_drvinfo callback and require
drivers to use that macro? Then the out-of-tree drivers are able to
replace that macro with whatever they need. Just don't forcibly bash
the value from higher up in the stack.
sln
next prev parent reply other threads:[~2020-01-26 22:21 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
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 [this message]
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=2a8d0845-9e6d-30ab-03d9-44817a7c2848@pensando.io \
--to=snelson@pensando.io \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=michal.kalderon@marvell.com \
--cc=netdev@vger.kernel.org \
/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).