Hi,
attached you'll find a couple of files: - sconfig.py.diff which is a patch against our current sconfig. The patch makes sconfig's output more predictable, by * reordering hard coded output so its elements match the order of the generated output * sorting registers alphanumerically by key * sorting headers alphanumerically. The third part contains a hack as I couldn't convince python that it should sort src/northbridge/amd/amdk8/root_complex/chip.h _after_ src/northbridge/amd/amdk8/chip.h (and the same for fam10)
This patch makes the output of sconfig more regular, but should otherwise not affect functionality.
The other files provide an implementation of sconfig in C. This has a couple of advantages: 1. We do not rely on python any longer 2. We use a commonly used compiler compiler (instead of yapps2) 3. It's faster (by a factor of 20, not that this matters much in absolute numbers) 4. It's smaller: 511LOC vs. 1035LOC (both excluding the compiler compiler), with code to drop once the byte-for-byte compatibility with python-sconfig can go.
sconfig.l and sconfig.y give you (with the help of bison and flex) an implementation of sconfig in C. I wrote a script that mass generated static.c files for all mainboards both with the python and the C version and diffed the results. With the patch to python-sconfig, these diffs are empty.
There are a couple of things left to do with the C version: - Hook up to the build system (in a way that flex and bison are optional dependencies, ie. deliver and by default use prebuilt results)
- Add static.dot generation code. This should be reasonably easy, now that the parsing and rewiring between the components is done. The emitter is a separate phase which doesn't change the internal device tree model.
- Clean up: -- There are various overly complicated things in the code to precisely match python-sconfig output where it wouldn't matter except to aid with the comparison (the order of the structs and includes) -- It's not so nice to stuff all the C code in sconfig.y. Parser and processing code should be split more sensibly. -- Naming: A couple of variables changed meaning over their life time. That's stable now, so they should be named intuitively. -- Strict parsing: For example, only accept registers for chips (python-sconfig doesn't do that properly, either)
Yet, I'd prefer to get the python-sconfig patch in, and the C code as similar to the current state as possible - It's known to give useful results. That way, further development provides history, so we can triage bugs more easily.
For the python patch, I'd need some help by someone with python knowledge about why it sorts the strings the way it does (the root_complex hack isn't acceptable for upstream)
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de