Ralf Baechle wrote:
> On Thu, Oct 04, 2007 at 09:33:08AM +0200, Franck Bui-Huu wrote:
>
>> Not really, I would say it's just an idea to remove tlbex.c from the
>> kernel code and to make it a tool called during compile time to
>> generate a handler skeleton which would be finalized by the kernel.
>
> IRIX was assembling its TLB exception handler from a few such skeletons
> or rather a few fractions. That works reasonably well as long as there are
> not too many variants - but Linux supports about anything on earth.
> Another disadvantage of the IRIX approach was that the fragments are
> written in assembler but the tacking together happens in C code so the
> code is split in a somewhat unnatural way over a few files.
>
That's what I was thinking too. It may require a lot of (ugly ?)
tricks to link the whole thing together. And if the idea was
previously used and showed it was inferior than what we have now, it's
just a bad idea.
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.
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...
OK, probably a bad idea (again) ...
Thanks
Franck
