[PATCH] Proposed update to the kernel kmap/kunmap API

From: James Bottomley
Date: Sun Aug 06 2006 - 11:00:05 EST

The simple part of the proposal is to give non-highmem architectures
access to the kmap API for the purposes of overriding (this is what the
attached patch does).

The more controversial part of the proposal is that we should now
require all architectures with coherence issues to manage data coherence
via the kmap/kunmap API. Thus driver writers never have to write code

modify data in page

instead, kmap/kunmap will manage the coherence and driver (and
filesystem) writers don't need to worry about how to flush between kmap
and kunmap. For most architectures, the page only needs to be flushed
if it was actually written to *and* there are user mappings of it, so
the best implementation looks to be: clear the page dirty pte bit in
the kernel page tables on kmap and on kunmap, check page->mappings for
user maps, and then the dirty bit, and only flush if it both has user
mappings and is dirty.


Index: linux-2.6/include/linux/highmem.h
--- linux-2.6.orig/include/linux/highmem.h 2006-07-26 17:51:09.000000000 -0700
+++ linux-2.6/include/linux/highmem.h 2006-07-26 17:51:18.000000000 -0700
@@ -29,6 +29,7 @@

static inline unsigned int nr_free_highpages(void) { return 0; }

+#ifndef ARCH_HAS_KMAP
static inline void *kmap(struct page *page)
@@ -41,6 +42,7 @@
#define kunmap_atomic(addr, idx) do { } while (0)
#define kmap_atomic_pfn(pfn, idx) page_address(pfn_to_page(pfn))
#define kmap_atomic_to_page(ptr) virt_to_page(ptr)

#endif /* CONFIG_HIGHMEM */

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/