Thiemo Seufer wrote: > Franck Bui-Huu wrote: >> Thiemo Seufer wrote: >>> Then you have the worst of both approaches: The nicely readable >>> disassembly will change under you feet, and you still need >>> relocation annotations etc. for CPU-specific fixups. The end-result >>> is likely more complicated and opaque than what we have now. >> Let say we generate handlers with all possible cpu fixups. Very few >> instructions would be removed so the disassembly should be quite >> similar after patching. > > No way. Just check the possible variations: 64bit, highmem, SMP, > and so on. > You just listed some variations that are known at compile time. What I meant by "all possible cpu fixups" is all fixups for a specific cpu which can be known only at runtime. >> And by emitting some nice comments in the >> generated code, it should be fairly obvious to get an idea of the >> final code. >> >> All fixups would be listed in a table with some flags to identify them >> and a list of instructions which need to be relocated. > > At that point you have invented something which effectively emits > the sourcecode for tlbex.c. > 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. Thanks, Franck
