Re: Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for2.6.27-rc1)
From: Linus Torvalds
Date: Thu Oct 23 2008 - 22:49:11 EST
On Thu, 23 Oct 2008, Keith Packard wrote:
> > So I'd much rather create a new <linux/kmap.h> or something. Or just
> > expose this from to <asm/fixmap.h> or something. Let's not confuse this
> > with highmem, even if the implementation _historically_ was due to that.
> Sure, we readily admit that we're abusing the highmem API. So we wrapped
> that abusive code in a pretty package that can be re-implemented however
> you desire.
> How (and when) would you like to see this fixed?
I'm not entirely sure who wants to own up to owning that particular part
of code, and is willing to make kmap_atomic_prot_pfn() also work in the
absense of CONFIG_HIGHMEM.
I suspect it's Ingo, but I also suspect that he'd like to see a tested
patch by somebody who actually _uses_ this code.
So I would suspect that if you guys actually write a patch, and make sure
that it works on x86-32 even _without_ CONFIG_HIGHMEM, and send it to
Ingo, good things will happen.
As to the "without CONFIG_HIGHMEM" part: making all of this work even
without HIGHMEM should literally be a matter of:
- remove the '#ifdef CONFIG_HIGHMEM' in <asm/fixmap_32.h>, so that we
have fixmap entries for the temporary kernel mappings regardless (ie
FIX_KMAP_BEGIN and FIX_KMAP_END).
- move the code for the atomic accesses that use those fixmap entries
into a file that gets compiled regardless of CONFIG_HIGHMEM. Or at
least just kmap_atomic_prot_pfn() and kunmap_atomic().
and it probably should all work automatically. The kmap_atomic() stuff
really should be almost totally independent of CONFIG_HIGHMEM, since it's
really much more closely related to fixmaps than HIGHMEM.
I guess there may be some debugging code that depends on HIGHMEM (eg that
whole testing for whether a page is a highmem page or not), so it might be
a _bit_ more than just moving code around, but I really didn't look
Then, there's the issue of 64-bit, and just mapping everything there, and
the interface to that. I liked the trivial extension to "struct resource"
to have a "cached mapping" pointer. So if we can just make it pass
resources around and get a page that way (and not even need kmap() on
64-bit architections), that would be good.
It's too late for -rc1 (which I'm planning on cutting within the hour),
and if it ends up being complex, I guess that it means this will eb a
But if it really is just a matter of mostly just some trivial code
movement and both the gfx and x86 people are all happy, I'll happily take
it for -rc2, and we can just leave this all behind us.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/