Re: [coreboot] A case for branching AGESA

[Patrick Georgi]

Alex,

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. :
> 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.


Patrick
-- 
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

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Coreboot hackaton 2016 (proposal in Paris)

[echelon]

Dear coreboot friends,

As discussed briefly in the last minutes of the Bonn meeting, I propose 
to organize the next coreboot hackaton in Paris in 2016.
Here is my plan (in broad lines, to be refined subsequently):
  - the venue would be hosted by the Electrolab, the famous hackerspace in
 Paris (www.electrolab.fr);
  - this time the meeting would be more of the "hackaton type" as in "come
 when you want, stay as much you want and hack as much as you can.." ;-)
  - after some preliminary discussions with the Electrolab, the access to the 
lab
 would be granted during a full week from morning to midnight (except monday);
  - given that Electrolab features some "conference" or "teaching" rooms, it 
will
 be possible to organize even some conferences (or "lightning talks") but 
 I do not plan to impose a "tight" schedule, so everyone who is interested to 
speak
 about something will be able to do so in a "self-organized session" manner 
 (like those of the CCC Camp 2015);
  - for the logistic side : Electrolab can take care for the catering part 
(there 
 is a big kitchen in Electrolab!) but not for the accomodation part. For this 
one,
 I will take care myself and send a list of suitable hotels later if this event 
 will materialize..

Now, I would like to know if someone else is interested to organize the 
coreboot 
hackaton in 2016 (maybe your proposal would be better that mine in which case 
I'm
ready to withdraw my proposal!..) and also I invite you to answer the next 
Doodle :
http://doodle.com/poll/6udccyrsqtqy2ndt
 to have an idea of the number of people interested in this hackaton proposal.

Best regards,
 Florentin Demetrescu

PS : initially I planned to schedule this hackaton near the FOSDEM 2016, but 
after 
some discussions with Ron and Stefan, I realize that maybe this is not the best 
timeframe..


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] A case for branching AGESA

[ron minnich]

So, if someone came to me with this problem:
building all the targets is slow
and this solution:
get rid of a bunch of them

I'd tell them to go back for more data, because that's just not enough
information.

Why's it slow? Where's the time going? How many files, on average, are part
of an AGESA build vs., e.g., a newer chromebook build? How big are they?
How many files do they include?

But sawing off one's leg because it hurts seems like a rushed decision.

So, what's going on here? Can we get a bit more specific about the problem,
and a bit less drastic about the solution?

ron
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] A case for branching AGESA

[Alex G.]

On 11/01/2015 12:49 AM, Patrick Georgi wrote:
> Just a note: the only reason why current Intel fares better

I didn't say Intel fares better. FSP is on my (rather long) hitlist, but
that's not within the scope of this discussion.

>> 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.

Thank you for creating the 'what-jenkins-does' make target.

>> 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...

And that's expected. Convergence is a dream. AGESA boards use BuildOpts
for configuration, and not much Kconfig/devicetree.cb, versus most other
boards in the tree. Except for VX900 and sandybridge, every chipset
implements its own SPD parsing routines. I can go on and on. Even within
one branch, significant divergence exists, so non-divergence is a moot
point.

Alex

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot