[coreboot] [RFC]Static testing of our tree

[Patrick Georgi]

Hi,

I'm currently thinking about various tests we could do on our tree to
avoid regressions, not just in functionality (which is somewhat hard to
do with all the board specific code we have), but also in style and
practices.

My first attempt is the attached script
(lint-001-no-global-config-in-romstage), which checks for preprocessor
symbols defined in mainboard romstages that are used elsewhere in the tree.
As you can see from my other mails these days, I'm currently trying to
cut down on these, by moving them to Kconfig.
This has several reasons: First, it's necessary to have these symbols
available globally when we start building the romstage in more separate
compilation units (more on that below). Second, it's basically a second
configuration mechanism besides the one we have, which is Kconfig.

The script, when run from the top level directory of a coreboot
checkout, emits the symbols that are defined in some romstage and are
used elsewhere. No further information is given as the idea is to give a
relatively quick overview on the tree, and fetching a list of files
where those symbols are in use would be expensive.

I propose to store this script (and similar ones) somewhere under util/,
and hook them up in the Makefile ("make lint"?) and in the autobuilder
(qa.coreboot.org), and have that report failure if they return any output.
That way, no change can readd this "second config system" without being
noticed.
I don't propose to do this now - that would mean that the autobuilder
reports errors for the next couple of weeks, but once we got the tree in
shape that it passes the test of the script, it could go in and make
sure that this issue doesn't come up again.

Another test could ensure that no mainboard code (and maybe even more
parts of the tree later-on) #includes *.c files.
That effort is useful because smaller compilation units make it easier
to track down bugs, to validate code, and so on.
If I ask you, could you tell (without looking) if init_cpus.c or
fidvid.c should be included first on an AMD K8/Fam10 board? It shouldn't
matter, but it does.

It's init_cpus.c, by the way ;-)

External tools, such as lint, splint could also be added into that
framework, should they be actually useful for our code (many aren't
because of their assumptions on C coding within OS environments).

This mail is marked RFC for a reason - what do you think?

Regards,
Patrick