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.
> 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.
> It seems to me that the kernel code would be much simpler than what we
> have now. Regarding the script used to generate the assembly code, if
> think it would be too.
I doubt that.
Thiemo
|