On Wed, Oct 03, 2007 at 02:17:56PM +0200, 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. > > Just a thought but I'm probably missing something. We went for the runtime generation because this is about the only sane way we can get support for the widest range of cores yet not compromise on performance. Maintaining the previous generation of that code which was like a dozen variants of page clearing, copying and TLB exception handlers was definately more tedious than this. Ralf
