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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 8AA67ECE589 for ; Sat, 5 Oct 2019 07:08:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 62416222BE for ; Sat, 5 Oct 2019 07:08:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570259313; bh=KgBJS2KS4Us8rDmrlnbSAKH/YQf5U12is/W8MDpz1q4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=Ufd97NwKN1FFxF6uJHVnBLzQ7WyQ9Y/P6Jpqy1Vc1wWfDsOj9B0dMPU747GCOG/ad 49edsfC2vf/yHnPVCj7TZXI5XMxb+uUb21rJIw12PbOOhT7H8cVzMXXV2AxmBV6wv2 m7nE8lffLdL9OpWf+bfkOZI+R5wUYBcHbFwVTT3Q= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727171AbfJEHIc (ORCPT ); Sat, 5 Oct 2019 03:08:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:55254 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725796AbfJEHIc (ORCPT ); Sat, 5 Oct 2019 03:08:32 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 264D92084D; Sat, 5 Oct 2019 07:08:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570259310; bh=KgBJS2KS4Us8rDmrlnbSAKH/YQf5U12is/W8MDpz1q4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TDTwdRoGRTpnBukfIAfQrR42wgmzAFEfoad6pWqbRhsfxexHpgDvb9VsudzkgTwQ9 jJDbPH83yiM8k+8FDV1/TFiDrnkh+L9WHvPV3ZdszoRzKb2JOF96d0moB5L9erGdFv Ae2LXNuOXd8hW3c7YOiUf+DlDDfT2THnvqvw5ENk= Date: Sat, 5 Oct 2019 09:08:27 +0200 From: "gregkh@linuxfoundation.org" To: Leon Romanovsky Cc: Jeff Kirsher , Jason Gunthorpe , "dledford@redhat.com" , Mustafa Ismail , "netdev@vger.kernel.org" , "linux-rdma@vger.kernel.org" , Shiraz Saleem Subject: Re: [RFC 04/20] RDMA/irdma: Add driver framework definitions Message-ID: <20191005070827.GA929891@kroah.com> References: <20190926164519.10471-1-jeffrey.t.kirsher@intel.com> <20190926164519.10471-5-jeffrey.t.kirsher@intel.com> <20190926173046.GB14368@unreal> <04e8a95837ba8f6a0b1d001dff2e905f5c6311b4.camel@intel.com> <20191004234519.GF13974@mellanox.com> <20191005062805.GP5855@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191005062805.GP5855@unreal> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sat, Oct 05, 2019 at 09:28:05AM +0300, Leon Romanovsky wrote: > On Fri, Oct 04, 2019 at 05:46:15PM -0700, Jeff Kirsher wrote: > > On Fri, 2019-10-04 at 23:45 +0000, Jason Gunthorpe wrote: > > > On Fri, Oct 04, 2019 at 01:12:22PM -0700, Jeff Kirsher wrote: > > > > > > > > > + if (ldev->version.major != I40E_CLIENT_VERSION_MAJOR || > > > > > > + ldev->version.minor != I40E_CLIENT_VERSION_MINOR) { > > > > > > + pr_err("version mismatch:\n"); > > > > > > + pr_err("expected major ver %d, caller specified > > > > > > major > > > > > > ver %d\n", > > > > > > + I40E_CLIENT_VERSION_MAJOR, ldev- > > > > > > >version.major); > > > > > > + pr_err("expected minor ver %d, caller specified > > > > > > minor > > > > > > ver %d\n", > > > > > > + I40E_CLIENT_VERSION_MINOR, ldev- > > > > > > >version.minor); > > > > > > + return -EINVAL; > > > > > > + } > > > > > > > > > > This is can't be in upstream code, we don't support out-of-tree > > > > > modules, > > > > > everything else will have proper versions. > > > > > > > > Who is the "we" in this context? > > > > > > Upstream sensibility - if we start doing stuff like this then we will > > > end up doing it everwhere. > > > > I see you cut out the part of my response about Linux distributions > > disagreeing with this stance. > > > > > > > > > you support out-of-tree drivers, they do exist and this code would > > > > ensure that if a "out-of-tree" driver is loaded, the driver will do a > > > > sanity check to ensure the RDMA driver will work. > > > > > > I don't see how this is any different from any of the other myriad of > > > problems out of tree modules face. > > > > > > Someone providing out of tree modules has to provide enough parts of > > > their driver so that it only consumes the stable ABI from the distro > > > kernel. > > > > > > Pretty normal stuff really. > > > > Your right, if the dependency was reversed and the out-of-tree (OOT) driver > > was dependent upon the RDMA driver, but in this case it is not. The LAN > > driver does not "need" the RDMA driver to work. So the RDMA driver should > > at least check that the LAN driver loaded has the required version to work. > > Not in upstream code, there is an expectation that kernel and modules are aligned. s/expectation/requirement/ If you do not do that, all bets are off. Distros can decide to do whatever they want with their kernels, but that's not what we require upstream. thanks, greg k-h