Re: [coreboot] A case for branching AGESA

[Alex Gagniuc]

On Wed, Nov 4, 2015 at 8:09 AM, Martin Roth  wrote:
> Let's table the discussion of agesa (and other) platform removal for
> now.

I didn't talk about removal. I don't understand why people think
"removal" in the context of the discussion I _attempted_ to start.
Let's also table the discussion about agesa (and other) platform
branching.

I'm looking forward to seeing the draft of the removal plans. Maybe
removal is even better than branching.

Alex

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

Re: [coreboot] A case for branching AGESA

[Martin Roth]

Hi Alex,

Sorry, I should have said 'removal from the coreboot master branch'.
That's what we're discussing in both contexts.  All 'removed' chips
and platforms will still be accessible in one of the version branches
if desired.  Nico demonstrated this today by cherry-picking patches
over to the 4.2 branch.

Martin

On Wed, Nov 4, 2015 at 3:02 PM, Alex Gagniuc  wrote:
> On Wed, Nov 4, 2015 at 8:09 AM, Martin Roth  wrote:
>> Let's table the discussion of agesa (and other) platform removal for
>> now.
>
> I didn't talk about removal. I don't understand why people think
> "removal" in the context of the discussion I _attempted_ to start.
> Let's also table the discussion about agesa (and other) platform
> branching.
>
> I'm looking forward to seeing the draft of the removal plans. Maybe
> removal is even better than branching.
>
> Alex

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

Re: [coreboot] A case for branching AGESA

[Martin Roth]

Let's table the discussion of agesa (and other) platform removal for
now.  As Patrick said in the 4.2 release announcement, a plan for the
removal of code is being written and will be posted for discussion
shortly.

Martin

On Tue, Nov 3, 2015 at 12:58 PM, Timothy Pearson
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/03/2015 03:41 AM, Vladimir wrote:
>> I strongly disagree with this branching "solution". Why?
>> Because - if building all the targets is slow - then just don't build
>> all the targets at once! If you need a fast build and you are not
>> concerned about AMD boards - just because you don't have any - it is
>> always possible to skip AGESA build without moving it to a branch and
>> separating from the rest of the coreboot code . So this is seen as a
>> really bad excuse
>>
>> Best regards,
>> Vladimir Shipovalov
>
> I do agree technically with this, however there's no policy in place for
> what happens when an AGESA build finally does fire and it's found the
> related source broke some time ago.  I think that's the main reason for
> wanting to stuff AGESA in a branch; separation of maintainaince.
>
> One one hand, having recently been the victim of having some of my
> native init patches fail Jenkins builds due to AGESA breakage, I'd
> almost like to see this happen.  On the other hand, I know exactly how
> painful sync across branches can be, so I can't recommend it.
>
> - --
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> http://www.raptorengineeringinc.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJWORHbAAoJEK+E3vEXDOFbfbgH/i5wk3vQrqtlAuCY0Jhdx2ML
> ez0ugczbnHaRiQZAuf62oQn1A2oPWg25LFssokztv9MyaJ1p1JbYkt1sLLJL5Eoi
> hHwm3Lr61oM4NWkHYIy8s1TiK2nIAWnw2gepulNePe9vlul0CiMFlqMon8FMoYCC
> 6cONRC/09ElLElPRazp5JkoOJnqWTxWotKJqYUJwoxQ7ed2f0L6WB45KWFZSpz3W
> PsO/WEX5TmsxiXLoV8q2W9NYizfNoDV/TIs89aKskcylxSCdj3DYWKYMudLAvglK
> wpsfJWuy7WRw01Lp+Av6aPeF0rzU+pP/z9JhzewZWTBryjl9KJ2mQEI1MbjJwtE=
> =3wXn
> -END PGP SIGNATURE-
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] A case for branching AGESA

[Vladimir]

I strongly disagree with this branching "solution". Why?
Because - if building all the targets is slow - then just don't build all
the targets at once! If you need a fast build and you are not concerned
about AMD boards - just because you don't have any - it is always possible
to skip AGESA build without moving it to a branch and separating from the
rest of the coreboot code . So this is seen as a really bad excuse

Best regards,
Vladimir Shipovalov




On 3 November 2015 at 01:14, Peter Stuge  wrote:

> Alex G. wrote:
> > >> users of AGESA can continue to contribute and work on the codebase.
> > > ... and diverge...
> >
> > And that's expected. Convergence is a dream.
>
> I disagree. I think it's a goal rather than a dream.
>
> > AGESA boards use BuildOpts for configuration, and not much
> > Kconfig/devicetree.cb
>
> I've done a bit of work on moving BuildOpts config for IDS into Kconfig,
> but it's not quite ready yet. I wrote the change dry and the only
> test data I have available reports coreboot not working after
> applying it. :) Sometime..
>
>
> > SPD parsing routines. I can go on and on.
> > non-divergence is a moot point.
>
> I disagree - I think we need to work towards less divergence rather
> than move in a direction which is likely to create more divergence.
>
> That's the only way to keep the codebase maintainable - which we all
> want. It was clear to me already when we saw the very first code from
> AMD that integration into our own codebase would take a while.
>
> I don't want to remove contributed code until we've given that a real shot.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] A case for branching AGESA

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/03/2015 03:41 AM, Vladimir wrote:
> I strongly disagree with this branching "solution". Why?
> Because - if building all the targets is slow - then just don't build
> all the targets at once! If you need a fast build and you are not
> concerned about AMD boards - just because you don't have any - it is
> always possible to skip AGESA build without moving it to a branch and
> separating from the rest of the coreboot code . So this is seen as a
> really bad excuse
> 
> Best regards,
> Vladimir Shipovalov

I do agree technically with this, however there's no policy in place for
what happens when an AGESA build finally does fire and it's found the
related source broke some time ago.  I think that's the main reason for
wanting to stuff AGESA in a branch; separation of maintainaince.

One one hand, having recently been the victim of having some of my
native init patches fail Jenkins builds due to AGESA breakage, I'd
almost like to see this happen.  On the other hand, I know exactly how
painful sync across branches can be, so I can't recommend it.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJWORHbAAoJEK+E3vEXDOFbfbgH/i5wk3vQrqtlAuCY0Jhdx2ML
ez0ugczbnHaRiQZAuf62oQn1A2oPWg25LFssokztv9MyaJ1p1JbYkt1sLLJL5Eoi
hHwm3Lr61oM4NWkHYIy8s1TiK2nIAWnw2gepulNePe9vlul0CiMFlqMon8FMoYCC
6cONRC/09ElLElPRazp5JkoOJnqWTxWotKJqYUJwoxQ7ed2f0L6WB45KWFZSpz3W
PsO/WEX5TmsxiXLoV8q2W9NYizfNoDV/TIs89aKskcylxSCdj3DYWKYMudLAvglK
wpsfJWuy7WRw01Lp+Av6aPeF0rzU+pP/z9JhzewZWTBryjl9KJ2mQEI1MbjJwtE=
=3wXn
-END PGP SIGNATURE-

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

Re: [coreboot] A case for branching AGESA

[Peter Stuge]

Alex G. wrote:
> >> users of AGESA can continue to contribute and work on the codebase.
> > ... and diverge...
> 
> And that's expected. Convergence is a dream.

I disagree. I think it's a goal rather than a dream.

> AGESA boards use BuildOpts for configuration, and not much
> Kconfig/devicetree.cb

I've done a bit of work on moving BuildOpts config for IDS into Kconfig,
but it's not quite ready yet. I wrote the change dry and the only
test data I have available reports coreboot not working after
applying it. :) Sometime..


> SPD parsing routines. I can go on and on.
> non-divergence is a moot point.

I disagree - I think we need to work towards less divergence rather
than move in a direction which is likely to create more divergence.

That's the only way to keep the codebase maintainable - which we all
want. It was clear to me already when we saw the very first code from
AMD that integration into our own codebase would take a while.

I don't want to remove contributed code until we've given that a real shot.


//Peter

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

Re: [coreboot] A case for branching AGESA

[Stefan Reinauer]

* Alex G.  [151101 21:29]:
> Except for VX900 and sandybridge, every chipset implements its own SPD
> parsing routines.
 
Gee, let's keep VX900 around then, it's one of the few good examples ;)

> Alex

Stefan

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

Re: [coreboot] A case for branching AGESA

[Patrick Georgi]

2015-11-01 21:29 GMT+01:00 Alex G. :
>>> 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.
So you picked three examples. Let me give several counter examples:
1. cbfs/fmap (backward and forward compatible): extended attributes,
file-level compression, hashes
2. vboot2/verstage integration
3. SPI flash driver infrastructure
4. supporting build tool development (eg. Kconfig improvements,
tighten lint rules) + the fallout to keep the tree compliant to the
new standards.

All of these would be painful to port between code bases (and some
were, see the chromeos-2013.04 branch).

Just because your three go-to items aren't as wonderful as (you claim)
you'd like them to be doesn't mean that you get to inflict damage on
other developers.


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

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

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