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

[James Bottomley]

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
like

kmap(page)
modify data in page
flush_kernel_dcache_page(page)
kunmap(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.

James

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)
 {
        might_sleep();
@@ -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
 
 #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/