Franck Bui-Huu wrote:
> Ralf Baechle wrote:
> > I don't mind - it's just that I've never been a friend of leaving much
> > debugging code or features around. 99% of the time it is just make the
> > code harder to read and maintain.
> Yeah this kind of code is really hard to follow and therefore hard to
> maintain I guess.
> I'm wondering if we couldn't try to implement such code generator by
> using a tools/scripts during the build process.
> This tool could emit
> the assembler code during the early phase of the build into an
> assembler file and then it could compiled like any other one. I see a
> 3 main benefits:
> - It would simplify a lot the kernel code.
> - Decrease the size of the kernel
> - Easy to read the generated disassembly
> One issue to deal with is that some instructions need to be emitted
> according to the type of the cpu which can only be determined at run
> time. In this case we could leave some rooms into the generated code
> for additional instructions which could be filled/patched during the
> boot time by using a 'patch table'. If the cpu doesn't need to patch
> the generated code then the useless space would be discarded when
> installing the handler in its final place.
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.