Maciej W. Rozycki wrote: > 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. > Yes, but some systems out there have some constraints on their boot time and others have ones on their persistent storage device size. >> 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. > Just to be sure I haven't missed anything, it seems that we _could_ generate the whole tlb handler at compile time since the CPU type is known at that time, no need to have any fixups at runtime, isn't it ? Franck
