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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 6A14BC35247 for ; Mon, 27 Jan 2020 06:46:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 410F12071E for ; Mon, 27 Jan 2020 06:46:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580107565; bh=VWfxKMgYxtmft2I94grJMun2sEl4Bw81GpK4/84mS0Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=1+6j51M2/Y4FHmEynREqFKCeuqcS9dTgr2aXoO3zKq1vqRkF1Mj4TZ0+X6YhTEXGy 54rPsDwnVsGJEquwu+UHWKan4Eei0RZAHwuQqPxqfWq4u8+VG6i2NGE1S/TWc4ARbU ZgNf0RJDYdOnorzSQmp/wlnct1huLysAN1dpjeA4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726922AbgA0GqE (ORCPT ); Mon, 27 Jan 2020 01:46:04 -0500 Received: from mail.kernel.org ([198.145.29.99]:49220 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725775AbgA0GqE (ORCPT ); Mon, 27 Jan 2020 01:46:04 -0500 Received: from localhost (unknown [213.57.247.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EE0F62071E; Mon, 27 Jan 2020 06:46:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580107563; bh=VWfxKMgYxtmft2I94grJMun2sEl4Bw81GpK4/84mS0Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WRm/bzQAOhn8EOAE9fKpN91v6dAqDfWtkT214YAX6TBlZ35B+mJom9EeHKPTeC9qb fd2aC3MjV39E68vFuhhLrNYvdlkhIKX4/TZxJ0h7GN4LxoJ/Eq+L+d9QaU/6GSL7ms zKSfGIikA8VJ6aGtAJzvCGG6yFYFXgpEWs6KsJRk= Date: Mon, 27 Jan 2020 08:45:34 +0200 From: Leon Romanovsky To: Shannon Nelson Cc: Jakub Kicinski , "David S . Miller" , Michal Kalderon , linux-netdev , RDMA mailing list Subject: Re: [PATCH net-next] net/core: Replace driver version to be kernel version Message-ID: <20200127064534.GJ3870@unreal> 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> <2a8d0845-9e6d-30ab-03d9-44817a7c2848@pensando.io> <20200127053433.GF3870@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200127053433.GF3870@unreal> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Jan 27, 2020 at 07:34:33AM +0200, Leon Romanovsky wrote: > On Sun, Jan 26, 2020 at 02:21:58PM -0800, Shannon Nelson wrote: > > 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. > > Thanks, it is another great example of why trusting driver authors, > even experienced, on specific topics is not an option. > > > > > 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. > > The thing is that we don't consider in-kernel API as stable one, so > addition of new field which is not in use in upstream looks sketchy to > me, but I have an idea how to solve it. Actually, it looks like my idea is Jakub's and Michal's idea. I will use this opportunity and remove MODULE_VERSION() too. Thanks > > Thanks > > > > > sln > >