From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 1A570607C7 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752319AbeFFHHF (ORCPT + 25 others); Wed, 6 Jun 2018 03:07:05 -0400 Received: from verein.lst.de ([213.95.11.211]:36081 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751899AbeFFHHE (ORCPT ); Wed, 6 Jun 2018 03:07:04 -0400 Date: Wed, 6 Jun 2018 09:14:18 +0200 From: Christoph Hellwig To: Dan Williams Cc: Jerome Glisse , Dave Airlie , Andrew Morton , Logan Gunthorpe , Christoph Hellwig , Michal Hocko , Linux MM , Linux Kernel Mailing List Subject: Re: [PATCH 0/5] mm: rework hmm to use devm_memremap_pages Message-ID: <20180606071418.GA7660@lst.de> References: <20180605184811.GC4423@redhat.com> <20180606000822.GE4423@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 05, 2018 at 06:33:04PM -0700, Dan Williams wrote: > Unless the nouveau patches are using the entirety of what is already > upstream for HMM, we should look to pare HMM back. > > There is plenty of precedent of building a large capability > out-of-tree and piecemeal merging it later, so I do not buy the > "chicken-egg" argument. The change in the export is to make sure we > don't repeat this backward "merge first, ask questions later" mistake > in the future as devm_memremap_pages() is continuing to find new users > like peer-to-peer DMA support and Linux is better off if that > development is upstream. From a purely technical standpoint > devm_memremap_pages() is EXPORT_SYMBOL_GPL because it hacks around > several implementation details in the core kernel to achieve its goal, > and it leaks new assumptions all over the kernel. It is strictly not a > self contained interface. Agreed with all of that. And remember EXPORT_SYMBOL_GPL really just is a clear expression of the authors they think these are internals. The lack of it doesn't make it any less a derived work, we just remove a very clear hint to users that they are poking very deeply into internals. And with HMM they very clearly do.