[coreboot] [announce] coreboot for the 21st century

[Stefan Reinauer]

* Vladimir 'φ-coder/phcoder' Serbinenko <phcoder at 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 at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot