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 D47E9C32771 for ; Mon, 27 Jan 2020 05:34:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A25E520842 for ; Mon, 27 Jan 2020 05:34:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580103277; bh=AN8xcbeAswCLKrMQKmHd+ictWwzTZpXA28r44lXQ/Fg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=BNiUJ4HWNDxV2mOG8LaJMnqO5ZDaPsUndJXQIS5NClbWCakCY90zKnHdus7+/ymNz OHnWqG6zP7UZOd4oc+illzyfWx5jOwsEwHabk8g6bgSwgfxJU+KzEuGGXAdB/3o3a3 X4GtFHBd3qK2+YrLkfKyuRIQwNRVOej5TTF7vCgk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725775AbgA0Feh (ORCPT ); Mon, 27 Jan 2020 00:34:37 -0500 Received: from mail.kernel.org ([198.145.29.99]:34916 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725763AbgA0Feg (ORCPT ); Mon, 27 Jan 2020 00:34:36 -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 80C1120842; Mon, 27 Jan 2020 05:34:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580103276; bh=AN8xcbeAswCLKrMQKmHd+ictWwzTZpXA28r44lXQ/Fg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=u+L9PgCJVXK+J/rTMLvAUh8kcw71LjCNNYBOvBl5fT4+AcXcsiFy4icosh5+9A2px eEa5wkABLZYCeFyY9U6F4lN7aMxjQ54XVXsCQ62mzNEYffxvVRRM6Pr3IRkWm9zrxf YYwrExasm1OHVd0ugu8auPWQLLyCaTcXu4Dcovng= Date: Mon, 27 Jan 2020 07:34:33 +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: <20200127053433.GF3870@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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2a8d0845-9e6d-30ab-03d9-44817a7c2848@pensando.io> Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org 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. Thanks > > sln >