From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8CB42C33CB7 for ; Mon, 27 Jan 2020 17:56:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5C3FE20CC7 for ; Mon, 27 Jan 2020 17:56:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=pensando.io header.i=@pensando.io header.b="OuGM7c8X" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725828AbgA0R43 (ORCPT ); Mon, 27 Jan 2020 12:56:29 -0500 Received: from mail-pl1-f194.google.com ([209.85.214.194]:34713 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725845AbgA0R42 (ORCPT ); Mon, 27 Jan 2020 12:56:28 -0500 Received: by mail-pl1-f194.google.com with SMTP id q13so4022174pls.1 for ; Mon, 27 Jan 2020 09:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pensando.io; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=jy43hP9+Df2cXG91F8i+OvLmTs0Ee2ULfkNV6G23utQ=; b=OuGM7c8XWlVqJY3cAhA5F8sgxpVMGSFQQZmm7Ljjh6XGXq37cl0WtRcxGrDL6XGOS4 JTenez/fGM+2mHc9MSaKQTd2wx82oTktPtFdrBTWE4obnhz4UfRrswNzNdjguwm2ffe5 e8lJR91rC8tgMraXt05kWgNyTBomE4mr4MOuvMxuq3Yg/u/z08Rd+3iqzcGz+Sv/tfGV rhQ4ntHvjTGvHDSFOaBboOLT+SZeJxayZsOiPUiNcEn6eY77r5VxxJjRgWUrQty8UMhw yH1I1umy6JmkSj4fSVk7aEG8oh2PvDMJOpT2Adfbn4QQPl7b+I742AFdyMyS0V3Ywpvt Abfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=jy43hP9+Df2cXG91F8i+OvLmTs0Ee2ULfkNV6G23utQ=; b=OYWFoYDbpCwLz4xHIpmMYcNFiq7cFfdFbtVNS3cLCBTgZiF80OTEXghf+mGx8DctNK AfJ49zmzSjCGr+ImPb28OBShBOH5T0tR5Ek2nOwlF849sB4CqRKV66thbWT7CMi6F/3P x1vZZ+ora0WVhCW6k5WS8q/YeoO2BbFgHr88Hj0XrDFGbsX7bhiMTQ+UpQkNbpMt7kJy Xb4DSeYQzAeATaEdx76Ev8Fdyo5WHuygAAHihMUjb59C1PFURa5B+EH7j1aqtZbNPT98 ge45VMnLITZZ1mnvz1wp0+smd77suy212GE8BUWH+Pj7vaIU8rJlhPbi5AhT9APUmJIW wjgw== X-Gm-Message-State: APjAAAW1WusPXECBIZrY1XN/rbuPAYytNGZq1DgnHQ7jDIN/IFuTvRyT ZGP8hxdcc9V3haWT3xDULZVjvzzvxNdTRg== X-Google-Smtp-Source: APXvYqzfJ38a2gp3IshboAGe+2sjpLAxA1INBDVfhPryhOKiQE+gMlI090dFVpWrDmHGRsxXzNew5A== X-Received: by 2002:a17:90b:1110:: with SMTP id gi16mr226469pjb.110.1580147787088; Mon, 27 Jan 2020 09:56:27 -0800 (PST) Received: from Shannons-MacBook-Pro.local (static-50-53-47-17.bvtn.or.frontiernet.net. [50.53.47.17]) by smtp.gmail.com with ESMTPSA id 133sm16675317pfy.14.2020.01.27.09.56.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Jan 2020 09:56:26 -0800 (PST) Subject: Re: [PATCH net-next] net/core: Replace driver version to be kernel version To: Leon Romanovsky , Jakub Kicinski Cc: "David S . Miller" , Michal Kalderon , linux-netdev , RDMA mailing list References: <20200123130541.30473-1-leon@kernel.org> <43d43a45-18db-f959-7275-63c9976fdf40@pensando.io> <20200126194110.GA3870@unreal> <20200126124957.78a31463@cakuba> <20200126210850.GB3870@unreal> <20200126133353.77f5cb7e@cakuba> <20200127054955.GG3870@unreal> From: Shannon Nelson Message-ID: <79bc446c-72a0-9209-98bc-e1d85a3a360a@pensando.io> Date: Mon, 27 Jan 2020 09:57:23 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200127054955.GG3870@unreal> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On 1/26/20 9:49 PM, Leon Romanovsky wrote: > On Sun, Jan 26, 2020 at 01:33:53PM -0800, Jakub Kicinski wrote: >> On Sun, 26 Jan 2020 23:08:50 +0200, Leon Romanovsky wrote: >>> 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. >>>> 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). >>> Shannon proposed to remove this field and it was me who said no :) >> Obviously, we can't remove fields from UAPI structs. >> >>> My plan is to overwrite ->version, delete all users and add >>> WARN_ONEC(strcpy(..->version_)...) inside net/ethtool/ to catch >>> abusers. >> What I was thinking just now was: initialize ->version to utsname >> before drivers are called, delete all upstream users, add a coccicheck >> for upstream drivers which try to report the version. >> >>>> 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 >> Right, upstream nfp reports kernel version (both in modinfo and ethtool) >> GitHub/compat/backport/out-of-tree reports kernel version in which the >> code was expected to appear in modinfo: >> >> https://github.com/Netronome/nfp-drv-kmods/commit/7ec15c47caf5dbdf1f9806410535ad5b7373ec34#diff-492d7fa4004d885a38cfa889ed1adbe7L1284 >> >> And git hash of the driver source plus out of tree marker in ethtool. >> >> That means it's out-of-tree driver which has to carry the extra code >> and require extra feeding. As backport should IMHO. >> >>>>> 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. >> Yeah... we all know it's not that simple :) > It is simple, unfortunately netdev people like to complicate things > by declaring ABI in very vague way which sometimes goes so far that > it ends more strict than anyone would imagine. > > We, RDMA and many other subsystems mentioned in that ksummit thread, > removed MODULE_VERSION() a long time ago and got zero complains from > the real users. > >> 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. >> >> Out of tree the field is useful, so we don't have to take it away just >> as a matter of principle. If we can't convince people to stop bringing >> the versions into the tree that'll be another story... > As Shannon pointed, even experienced people will try to sneak those > changes. I assume that it is mainly because they are pushed to do it > by the people who doesn't understand Linux kernel process. > I don't think that the Intel Networking folks were trying to "sneak" something through, I think they have simply been continuing the process that they've been following for years.  When we have groups such as them, with a long history of contributions to drivers and stack, not following the new rules, perhaps we need to take a look at how we're publicizing these changes. sln