On Mon, 8 Oct 2007, Franck Bui-Huu wrote: > 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. As long as the user is indeed capable of knowing what the exact CPU type is. I have been told replacing R4X00 with a choice like R4000, R4400, R4600, R4700 may already be too much of a hassle. Frankly I am not entirely confident much choice beyond the ISA level is actually a good idea. We do have it, because lots of bits depend on preprocessor conditionals even though they not necessarily should. There are probably some historical reasons too. But essentially we have about eight ISA variations (I - IV and four MIPS Architecture ISAs) and about four privileged resource architecture variations (R2000, R6000, R4000, R8000); not all combinations making sense and some of the choices actually not supported at all. CPU variations matter performance-wise, but the use of "-mtune=" is irrelevant in this context. > 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). What would be the gain for the kernel from using "-march=4ksd" rather than "-march=mips32r2"? > 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... I do not think we happen to handle this scenario -- the more interesting configurations that could benefit do not support the cp0.ebase register making per-CPU handlers quite a challenge (i.e. the cost would exceed the benefit). > 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 ? What if you want to run a single kernel image regardless of the CPU installed in the system. Rebuilding the kernel (or having to keep a large collection of binaries) just because you want to swap the CPU does not seem like a terribly attractive idea. Some systems come with their CPU(s) on a daughtercard (each), you know... Maciej
