From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 27 Jun 2019 08:41:06 +0200 From: Michal Hocko Subject: Re: [PATCH 05/22] mm: export alloc_pages_vma Message-ID: <20190627064106.GC17798@dhcp22.suse.cz> References: <20190613094326.24093-6-hch@lst.de> <20190620191733.GH12083@dhcp22.suse.cz> <20190625072317.GC30350@lst.de> <20190625150053.GJ11400@dhcp22.suse.cz> <20190625190038.GK11400@dhcp22.suse.cz> <20190626054645.GB17798@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: owner-linux-mm@kvack.org To: Dan Williams Cc: Christoph Hellwig , =?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 List-ID: On Wed 26-06-19 09:14:32, Dan Williams wrote: > On Tue, Jun 25, 2019 at 10:46 PM Michal Hocko wrote: > > > > On Tue 25-06-19 12:52:18, Dan Williams wrote: > > [...] > > > > Documentation/process/stable-api-nonsense.rst > > > > > > That document has failed to preclude symbol export fights in the past > > > and there is a reasonable argument to try not to retract functionality > > > that had been previously exported regardless of that document. > > > > Can you point me to any specific example where this would be the case > > for the core kernel symbols please? > > The most recent example that comes to mind was the thrash around > __kernel_fpu_{begin,end} [1]. Well, this seems more like a disagreement over a functionality that has reduced its visibility rather than enforcement of a specific API. And I do agree that the above document states that this is perfectly legitimate and no out-of-tree code can rely on _any_ functionality to be preserved. On the other hand, I am not really surprised about the discussion because d63e79b114c02 is a mere clean up not explaining why the functionality should be restricted to GPL only code. So there certainly is a room for clarification. Especially when the code has been exported without this restriction in the past (see 8546c008924d5). So to me this sounds more like a usual EXPORT_SYMBOL{_GPL} mess. In any case I really do not see any relation to the maintenance cost here. GPL symbols are not in any sense more stable than any other exported symbol. They can change at any time. The only maintenance burden is to update all _in_kernel_ users of the said symbol. Any out-of-tree code is on its own to deal with this. Full stop. GPL or non-GPL symbols are solely to define a scope of the usage. Nothing less and nothing more. > I referenced that when debating _GPL symbol policy with J�r�me [2]. > > [1]: https://lore.kernel.org/lkml/20190522100959.GA15390@kroah.com/ > [2]: https://lore.kernel.org/lkml/CAPcyv4gb+r==riKFXkVZ7gGdnKe62yBmZ7xOa4uBBByhnK9Tzg@mail.gmail.com/ -- Michal Hocko SUSE Labs