From: James Bottomley <James.Bottomley@xxxxxxx> Date: Wed, 03 Feb 2010 10:40:54 -0600 > Actually, thinking about the semantics, the normal kmap has to have > these flushes in the map and unmap anyway ... otherwise the page gets > decohered if you do normal read/write on it. The only information we > don't have in current kmap is whether we're mapping for read/write or > both. So the API I'd propose is keep current kmap as is for the read > and write case, and introduce a kmap_for_read and kmap_for_write (with > corresponding umaps, and obviously atomics). This would basically force non-highmem platforms to implement the kmap_*() interfaces. I understand that MIPS does this already to deal with cache aliasing. But that's currently a choice, and sparc64 for example has no need to do things that way. It would in fact be more expensive than how sparc64 currently handles cache aliasing. So I'm more in support of a new interface. Platforms like sparc64 can implement it and then get rid of the ide_*() string op cache flushes and instead we put the new API calls in the right spots. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
