In message 20030708024322.GA425@buici.com you wrote:
I'm sending an initial patch for the KEV7A400 dev board in order to get some feedback about the configuration extension I'm proposing. This is *not* complete. It ought not break any of the non-ARM9 builds though it may break one of the ARM9 ones.
I'll reject this patch for now, mostly for formal reasons.
* Please don't try to sneak in local stuff like your .gdbinit file.
* Please don't add lines with trailing white space.
* Please use the Linux kernel coding style. Please stick with TAB indentation, especially when editing existing code that uses it.
* Please do not use C++ comments.
* I would prefer if we would NOT add the requirement for more external tools (like Perl). But if you use these, then please use the respective recommendations for "good style" code - like using the "-w" switch and maybe "use strict;"
* You use "private" debugging clauses like "#ifdef RTC_DEBUG" - why not simply using the existing debug() macro?
Now for the technical discussion: I don't see much advantage when using your mkconfigx script. IMHO it has several problems: * It will incorrectly include files that have been commented out using C comments, "#if 0" or similar clauses. * It is based on the assumption that only CONFIG_* definitions are relevant; it would be nice if this was the case, but actually there is at least a couple of CFG_* variables, and some boards use (locally) even completely different names
You may argument that it's possible to fix the know problems, but I'm sure we will run into similar problems again later.
You modify include/asm-arm/processor.h in an unexpacted way (inserting "#undef arm"). Please don't add such code to system header files. Ther eis obviously a problem somewhere in your toolchain and/or on tyour system. Please fix the cause, not the symptoms.
May I please ask you to clean up the patch as far as the KEV7A400 dev board is concerned, and resubmit it. Please omit the mkconfigx stuff (and other "goodies" like .gdbinit).
Best regards,
Wolfgang Denk