[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180522143121.54d4ebced511277b923d31ba@linux-foundation.org>
Date: Tue, 22 May 2018 14:31:21 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Christoph Hellwig <hch@....de>
Cc: Dan Williams <dan.j.williams@...el.com>,
Jérôme Glisse <jglisse@...hat.com>,
Logan Gunthorpe <logang@...tatee.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] mm, hmm: mark hmm_devmem_{add, add_resource}
EXPORT_SYMBOL_GPL
On Tue, 22 May 2018 08:32:36 +0200 Christoph Hellwig <hch@....de> wrote:
> On Mon, May 21, 2018 at 03:35:40PM -0700, Dan Williams wrote:
> > The routines hmm_devmem_add(), and hmm_devmem_add_resource() are small
> > wrappers around devm_memremap_pages(). The devm_memremap_pages()
> > interface is a subset of the hmm functionality which has more and deeper
> > ties into the kernel memory management implementation. It was an
> > oversight that these symbols were not marked EXPORT_SYMBOL_GPL from the
> > outset due to how they originally copied (and now reuse)
> > devm_memremap_pages().
>
> If we end up keeping this code: absolutely. Then again I think without
> an actual user this should have never been merged, and should be removed
> until one shows up.
>
It wasn't simple. Quite a lot of manufacturers were (are?) developing
quite complex driver code which utilizes hmm. Merging hmm to give a
stable target for that development and in the expectation that those
things would be coming along was a risk and I don't think we yet know
the outcome.
Jerome, are you able to provide any updates on all of this?
Powered by blists - more mailing lists