[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160531172705.GJ11948@wotan.suse.de>
Date: Tue, 31 May 2016 19:27:05 +0200
From: "Luis R. Rodriguez" <mcgrof@...nel.org>
To: "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc: Christoph Hellwig <hch@...radead.org>,
Dan Williams <dan.j.williams@...el.com>,
Toshi Kani <toshi.kani@...com>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Will Deacon <will.deacon@....com>, X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
Julia Lawall <julia.lawall@...6.fr>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Borislav Petkov <bp@...en8.de>
Subject: Re: Enhancing semantics with memremap() - aliasing with memremap()
On Tue, May 31, 2016 at 07:25:14PM +0200, Luis R. Rodriguez wrote:
> On Tue, May 31, 2016 at 09:58:28AM -0700, Christoph Hellwig wrote:
> > On Tue, May 24, 2016 at 04:36:42PM -0700, Luis R. Rodriguez wrote:
> > > Is it a good time for that now? I would hope identifying proper
> > > aliasing uses for memremap() might be a bit easier now than for
> > > ioremap() given its not used as widely. It may be an easier target to
> > > also write some grammar rules for it as well.
> >
> > So you want an explicit opt-in flag to allow aliasing? Sounds fine to
> > me.
>
> Yup! Can the default then safely already be no-aliasing then?
Or if aliasing is truly not needed as often a different API, this
maybe useful later if we pick up again module namespace stuff.
Luis
Powered by blists - more mailing lists