On Mon, Oct 28, 2002 at 06:26:08AM -0800, David S. Miller wrote:
> If you can't get purely arch/* include/asm-* patches to him,
> that isn't my problem.
>
> Yes, you might have to retransmit that patch 20/30 times over the
> course of a few days depending upon how busy Linus is, just get over
> it. :-)
I've been more concerned with getting core changes we need to him than
updating arch/parisc and include/asm-parisc. Maybe I should have been
more pushy.
> What do you want to do about flush_icache_page? You want to change it
> to flush_dcache_page at eviction time, and then we can purge that page
> from our icache in update_mmu_cache?
>
> That's the idea. The other idea is "well these particular call spots
> really are special, so let's document flush_icache_page properly".
What data do you need to make that decision? AFAICT (I'm not really
a PA CPU guru..) it's exactly the same amount of code, no matter which
way we do it.
While we're on the subject of cache flushing... these make no sense:
fs/binfmt_aout.c:357: flush_icache_range(text_addr, text_addr+ex.a_text+ex.a_data);
fs/binfmt_aout.c:381: flush_icache_range((unsigned long) N_TXTADDR(ex),
fs/binfmt_aout.c:479: flush_icache_range((unsigned long) start_addr,
fs/binfmt_elf.c:422: flush_icache_range((unsigned long)addr,
the kernel doesn't execute the code ranges here, userspace does. Which
means that the only place in the entire kernel which does need to call
flush_icache_range() is kernel/module.c, and that could all be done in
module_arch_init(). So I think we don't need flush_icache_range() at all.
-- Revolutions do not require corporate support. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:37 EST