[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ynxh/5jewIuGwb5d@iweiny-desk3>
Date: Wed, 11 May 2022 18:25:19 -0700
From: Ira Weiny <ira.weiny@...el.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>,
Dan Williams <dan.j.williams@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Rick Edgecombe <rick.p.edgecombe@...el.com>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V10 33/44] kmap: Make kmap work for devmap protected pages
On Thu, Apr 28, 2022 at 08:50:34AM -0700, Christoph Hellwig wrote:
> On Tue, Apr 19, 2022 at 10:06:38AM -0700, ira.weiny@...el.com wrote:
> > index a77be5630209..32ed07c2994b 100644
> > --- a/include/linux/highmem-internal.h
> > +++ b/include/linux/highmem-internal.h
> > @@ -151,6 +151,8 @@ static inline void totalhigh_pages_add(long count)
> >
> > #else /* CONFIG_HIGHMEM */
> >
> > +#include <linux/memremap.h>
>
> Uuuh, I'd really prefer to avoid having to pull in memremap.h into
> basically the whole kernel build.
>
Fair enough. What should I call a header to store the new pgmap_set_*() calls?
devmap_prot.h
?
Or I could just add the calls into highmem-internal.h. That might be more
appropriate given the new direction of that interface.
I think I'm leaning toward that vs adding another header.
Ira
Powered by blists - more mailing lists