[coreboot] A case for branching AGESA

Patrick Georgi pgeorgi at google.com
Sun Nov 1 08:49:19 CET 2015


while I'm happy that you're providing hard numbers, I completely
disagree with your conclusion.
A much better approach, that doesn't rely on figuring out which parts
happen to be inconvenient to a subset of our developers, is to build
an analysis of the impact of a commit.

For global code changes, we _want_ everything to be build (and boot)
tested, while a change in src/mainboard/$foo/$bar, in principle, only
needs to build that single mainboard. Such an approach requires, and
here comes the (somewhat) hard part, that the scope of a change can be
determined reliably.

The speed-up of such an approach is close to optimal.

2015-11-01 1:36 GMT+01:00 Alex G. <mr.nuke.me at gmail.com>:
> AGESA is a very heavy beast, at over one and a half million lines of
> code.
Just a note: the only reason why current Intel fares better is because
they're shipping binaries that we can't even distribute in
3rdparty/blobs. Otherwise that looks pretty similar.

> 7 min vs 20 min on empty ccache, and 2 min vs 6 min on primed ccache.
> Those are speedups of 2x to 3x.
Thank you for doing the measurements.

> The obvious solution is to separate AGESA into its branch.
It may be obvious to you, but there were enough good arguments brought
up by a many good people that branches for such purposes aren't going
to happen.

> Patch trains from google and other contributions to non-AGESA code gain a 2x to 3x
> speedup in server time, while users of AGESA can continue to contribute
> and work on the codebase.
... and diverge...

> Since 4.2 was just released, we can do this today without much fanare.
We have nothing to hide, so "without much fanfare" doesn't need to factor in.

> To anyone saying that putting code in a branch is a death sentence,
I'm not a fan of such attempts at framing the debate.

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

More information about the coreboot mailing list