From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5AD4921296B17 for ; Tue, 25 Jun 2019 08:00:56 -0700 (PDT) Date: Tue, 25 Jun 2019 17:00:53 +0200 From: Michal Hocko 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-Disposition: inline In-Reply-To: <20190625072317.GC30350@lst.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Christoph Hellwig Cc: linux-nvdimm , nouveau@lists.freedesktop.org, Linux Kernel Mailing List , Maling list - DRI developers , Linux MM , =?iso-8859-1?B?Suly9G1l?= Glisse , Jason Gunthorpe , Ben Skeggs , linux-pci@vger.kernel.org List-ID: 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 _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm