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.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_MUTT 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 A2485C48BD6 for ; Tue, 25 Jun 2019 15:00:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 713BC208E3 for ; Tue, 25 Jun 2019 15:00:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561474857; bh=NS7Z6qjdyIhvJdu4ABGngGy2FlwYuKNFBpRUeTymwpA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=ecOesZdjrKm+LlxOmMa7WvZ1N7F6qKPgEN2aBFji5gfwjLHOjmgHMFQAQSLCDCjl6 8v0BlnYyFSQkB/ZLKke6lOuUUtKrI7Dehz2ijqG8WMOy+W20SVQpcoBdhi5+pnFNOL 5qltPaYGdFccdtb9+3CrWVLQQxOi80dFZQOHJGw4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732023AbfFYPA4 (ORCPT ); Tue, 25 Jun 2019 11:00:56 -0400 Received: from mx2.suse.de ([195.135.220.15]:59058 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731153AbfFYPA4 (ORCPT ); Tue, 25 Jun 2019 11:00:56 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 7BBA5AF4C; Tue, 25 Jun 2019 15:00:54 +0000 (UTC) Date: Tue, 25 Jun 2019 17:00:53 +0200 From: Michal Hocko To: Christoph Hellwig Cc: Dan Williams , =?iso-8859-1?B?Suly9G1l?= Glisse , Jason Gunthorpe , Ben Skeggs , Linux MM , nouveau@lists.freedesktop.org, Maling list - DRI developers , linux-nvdimm , linux-pci@vger.kernel.org, Linux Kernel Mailing List Subject: Re: [PATCH 05/22] mm: export alloc_pages_vma Message-ID: <20190625150053.GJ11400@dhcp22.suse.cz> References: <20190613094326.24093-1-hch@lst.de> <20190613094326.24093-6-hch@lst.de> <20190620191733.GH12083@dhcp22.suse.cz> <20190625072317.GC30350@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190625072317.GC30350@lst.de> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 25-06-19 09:23:17, Christoph Hellwig wrote: > On Mon, Jun 24, 2019 at 11:24:48AM -0700, Dan Williams wrote: > > I asked for this simply because it was not exported historically. In > > general I want to establish explicit export-type criteria so the > > community can spend less time debating when to use EXPORT_SYMBOL_GPL > > [1]. > > > > The thought in this instance is that it is not historically exported > > to modules and it is safer from a maintenance perspective to start > > with GPL-only for new symbols in case we don't want to maintain that > > interface long-term for out-of-tree modules. > > > > Yes, we always reserve the right to remove / change interfaces > > regardless of the export type, but history has shown that external > > pressure to keep an interface stable (contrary to > > Documentation/process/stable-api-nonsense.rst) tends to be less for > > GPL-only exports. > > Fully agreed. In the end the decision is with the MM maintainers, > though, although I'd prefer to keep it as in this series. I am sorry but I am not really convinced by the above reasoning wrt. to the allocator API and it has been a subject of many changes over time. I do not remember a single case where we would be bending the allocator API because of external modules and I am pretty sure we will push back heavily if that was the case in the future. So in this particular case I would go with consistency and export the same way we do with other functions. Also we do not want people to reinvent this API and screw that like we have seen in other cases when external modules try reimplement core functionality themselves. Thanks! -- Michal Hocko SUSE Labs