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
