On Thu, 4 Oct 2007, Franck Bui-Huu wrote: > It's just a bit sad to see my TLB handler generated at each boot and > to embed the whole tlbex generator inside the kernel which is quite > big: > > $ mipsel-linux-size arch/mips/mm/tlbex.o > text data bss dec hex filename > 10116 3904 1568 15588 3ce4 arch/mips/mm/tlbex.o > > specially if my cpu doesn't have any bugs. Well, most systems are there to work and not to be rebooted repeatedly all the time. ;-) All of tlbex.o is discarded after bootstrap. > Maybe having, 2 default implementations in tlbex-r3k.S, tlbex-r4k.S > for good cpus (the ones which needn't any fixups at all) and otherwise > the tlbex.c is used. And with luck the majority of the cpus are > good... Well, most of the differences are not due to CPU bugs, but different cp0 hazards. The MIPS32r2 and MIPS64r2 architecture specs introduce the "ehb" and "jr.hb" instructions to sort them out, but most of the processors we support predate them. The existence of the definitions in <asm/war.h> is there so that workarounds for CPU bugs are optimised away at the kernel build time if not activated. I agree the inclusion both R3k and R4k handlers at the same time even though any configuration predetermines which of the two is only going to be needed is a bit suboptimal indeed. Maciej
