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. Thiemo
