On Fri, 12 Jan 2001, you wrote: > Justin Carlson wrote: > > > > This is sort of true. Mips32 does do a pretty good job of defining how to > > probe for L1 caches and the like, but other things, such as L2 caches, are not > > going to be so easily probed. > > My understanding is that we don't have a standard way to probe for external > cache (L2 or L3). So this problem is not only for MIPS32 cpus. > It's not specific to mips32 processors, no. My point was, the mips32 spec doesn't (and probably shouldn't, IMHO) solve this problem completely. > > If I'm understanding your idea correctly, this table would require you to > > always compile in all the mmu routines for all processors, just to fill in the > > table entries. Doesn't seem like a particularly good idea to me, even if we > > could use generic mips32 routines for most parts. > > > > Each table entry can be surrounded by something like #if > defined(CONFIG_CPU_RM7000) and #endif. That should take care of the problem. > Not if you want to have constant-defined offsets into the table. Which is just about the only reason to use a table for this...Either: 1) You've got multiple entries in the table for different cpus, which you're indexing by some hash of PRID fields. This requires a full table. (Or a really ugly hash function that's adaptive depending on which which cpu support is compiled in) 2) You've got a single entry table. Unless I'm really misunderstanding what you're proposing... -Justin
