Andi Kleen <[EMAIL PROTECTED]> writes: > On Tuesday 30 August 2005 02:20, Eric W. Biederman wrote: >> PAT (or setting caching policy in the page table entries) has been a >> long desired feature in the kernel and as large memory sizes become >> more prevalent it becomes increasingly hard to specify all of the >> regions that need write-back caching with just 8 MTRRs much less add >> in the write-combining regions. > > [...] > > I don't think it's a good idea to provide the APIs for write combing > to drivers without offering the facilities to avoid aliasing. Because > otherwise we will need to change the API later anyways and there > might be code creep with driver source using old unsafe accesses. > So I would not merge it right now until it is more fully developed.
Everything I have provided is already there on some other architecture. Even the possibility for aliasing is already there on x86. How does my patch make anything worse? Andy what do you expect to see as a solution to the aliasing problem? Andy do you have any problem with my patch besides it does not solve a theoretical problem it does not even introduce? We need to get this at least into something like -mm where the community can review the code and do development. Denying the code access to more eyes sounds does not look like a way to solve the problem. As best I can tell guaranteeing that we do not do aliasing is a totally separate problem from PAT and it should be solved that way. This is a practical problem for me. I have hardware where mtrrs cannot be used to both map memory and setup all of the WC memory regions I need. So this patch solves a real problem at a very minimal impact to the kernel. The only way I can imagine the infrastructure working with the drivers in control (without rewriting all of the existing drivers) is to have ioremap and io_remap_pfn_range fail when presented with an attempt to map the same physical memory with different attributes. So from that perspective we already have enough infrastructure to do something. The only real problems exist when you mix WB and (UC or WC) and I have only made access to WC easier. Who is going to call ioremap or io_remap_pfn_range on ram? Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
