Re: [PATCH] mm/pg-r4k.c: Dump the generated code

[Franck Bui-Huu <vagabon.xyz@gmail.com>]

Maciej W. Rozycki wrote:
> The exact CPU type is not known at the moment.  For example CPU_R4X00 and 
> CPU_MIPS32_R1 cover whole ranges that have subtle differences.  It may be 
> possible to provide all the variations as a selection to the user, but it 
> may be unfeasible -- I don't know.  Compare what we have in 
> arch/mips/Kconfig with <asm/cpu.h>.
> 

OK, I see.

Well, having all cpu variations in Kconfig should be technically
possible. The user needs to know what exact cpu is running on which
doesn't sound impossible and we could add some sanity checkings to
ensure he doesn't messed up its configuration.

BTW, we could pass more cpu compiler options for optimization this
way. For example, when using a '4ksd' cpu, we currently can't pass
'-march=4ksd' to gcc since the cpu type used for it is 'mips32r2'. And
I guess it's true for all cpu types which cover a range of slightly
different processors (r4x00 comes in mind).

OTOH, I don't know if it can work on SMP: if the system needs 2
different implementations of the handler (I don't know if it can
happen though), we must be able to select 2 different cpu types in
Kconfig...

Do you see any other points that we should consider before trying to
use static handlers ? Some other cpu features influencing the tlb
handler generations and that can be found only at runtime ?

thanks,
		Franck