* Vladimir 'φ-coder/phcoder' Serbinenko phcoder@gmail.com [140321 04:13]:
The boards and chipsets are sufficiently well insulated from each other so that it's possible to improve one without breaking the others. With board-status the potential users and devs have a good overview which revisions work on which devices. The breakage will periodically occur no matter if it's 25 board or 250 boards. And it will be fixed by those who care about the particular board.
Somewhat agreed. Yet, there is a certain amount of technical debt caused by boards that went out of production in the early 2000s that keep us from creating clean designs across the board instead of hiding features inside of chipsets and boards. This is exactly what then leads to the problem you are describing next:
Also I feel like the amount of boards supported is actually a relatively minor maintenance burden compared to number of *options* supported. I think we should first go on killing the options noone really uses like possibility disabling ACPI tables (I have a changeset for this, mixed reception), disabling SMBIOS tables. "relocatable" modules should be chosen by chipset, not be user-visible, and so on. There are more broken option configurations than broken boards.
Absolutely agreed. When we moved from coreboot v2 to v4 with the little v3 detour we recognized that there are several levels of "configuration" that happened in Config.lb back then. These were: - build rules hidden in a board config. - board specific configuration (device tree) - user configs determined at build time - user configs determined at runtime (cmos etc)
A lot of that stuff ended up in the same file, and there was no clear abstraction. Then we moved to Kconfig, and away from creating Makefiles at compile time through a nasty python wrapper. However, parsing the device tree to provide compile time options in Kconfig seemed really troublesome, and so we "broke" our clean design of having device specific info in the device tree and only options in Kconfig. Once you go down that road, it becomes a dump really quickly, and now we have to clean up that stuff. My personal opinion is that providing non-choice options to users (like "turn off ACPI and break booting any OS newer than 10ys) are not real options and just messing with the user at the cost of making the build system more complicated.
All in all, there are lots of things awaiting to be fixed in the future.
Stefan
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot