Greetings all,

Patrick gregori said:
Mostly chatter on IRC, to be honest. Part of the intent of this mail was to surface this more officially.
It would be helpful to carry over more details when porting discussions from IRC. It is always good to be specific how something is broken, not just that the garbage collector is coming.

Kyösti said:
Since coreboot seems to accept blobs with ease nowadays, the solution to keep these platforms can be such that we move AGESA vendorcode to submodule. 
This is one way of handling it, but I don't think it does anything to address the quality of the code. Out of sight and out of mind, so to speak.

We can equally make such quality assurance arguments about FSP2.0, once commercial vendor gets something merged, they don't really care how much it gets in the way of overall architecture or subsystems evolution.
As Ron noted:
We kept it relatively the same when AMD was a player in coreboot, but they're long gone; time for major surgery?
I assume that AMD probably doesn't have any plans to revisit 15h if/when they follow through on porting 17h? :-) 

Patrik said:
This was about surfacing issues like these earlier, to reduce the amount of surprise. Having your status update on the C bootblock and CAR migration implementation is useful for that, too!
Is there a single point of reference for this kind of information, to avoid surprises?

Ron said:
Is this statement true?
"There is no source so bad that a binary blob is better"
Unless this is the trivial case where the blob boots and the code doesn't (or is otherwise functionally inferior), I would argue that any code can be compiled into a blob.
Thus, the code is automatically as-good-or-better. :-)

If we take that to be true, then what about this:
"bad source should never be replaced by a blob, but only by better source"
This is where things begin to come apart. The first part is true based on (1) but unless someone writes better source, eventually the code breaks and you enter the trivial case above. 

"we must never remove source that is in use if the only replacement is a blob"
If the code works (it is in use after all), then refer to (1). Otherwise, this is the trivial case.

Once you find yourself in the trivial case, you need to make the decision to either fix the broken code, or embrace the blob.

Sincerely,
    -Matt

On Thu, Sep 12, 2019 at 1:36 PM ron minnich <rminnich@gmail.com> wrote:
Interesting discussion! It got me to wondering, having spent a lot of
time in the V1, V2, and V3 trees the last few months.

Is this statement true?
"There is no source so bad that a binary blob is better"

If we take that to be true, then what about this:
"bad source should never be replaced by a blob, but only by better source"

From there:
"we must never remove source that is in use if the only replacement is a blob"

Would that help guide the decision on AGESA? Or is it just more bikeshedding :-)

I personally find the AgEsA cOdE quite UgLy, but ... it's code. I
wonder if it can't be fixed with a few
initial spatch passes. We kept it relatively the same when AMD was a
player in coreboot, but they're long
gone; time for major surgery?

I don't think we want to say "ugly code, nuke it" unless there is
replacement that is code.

ron



On Thu, Sep 12, 2019 at 9:46 AM awokd via coreboot
<coreboot@coreboot.org> wrote:
>
> Patrick Georgi via coreboot:
> > Hi everybody,
> >
> > coreboot is shipping AMD's open sourced AGESA for a few generations
> > as part of its tree.
> >
> > Some people advocate dropping the code due to its quality and lack
> > of maintenance while others are happy with using the code.
> >
> > So: to help keep this code alive, we'd need maintainers - people
> > willing to work through issues, improve the code quality and generally
> > act as a point of contact if any questions arise.
> >
> > One item to start with could be to work through Coverity
> > issues, where the largest proportion is now AGESA based
> > after Jacob cleaned up most of the rest of the tree. See
> > https://scan.coverity.com/projects/coreboot
>
> I would like to help out. Is there someone experienced who can mentor me
> on setting up a streamlined, open-source development environment for
> Coreboot? I've been using grep and gedit for my hacking needs, but
> trying to maintain a 5 level deep state table of AGESA code dependencies
> in my head was a problem. How did Jacob get started and what IDE did he
> use, for example?
>
> > Drivers needs support to not get in the way of later development,
> > and AGESA is sorely lacking in that department. If you see value
> > in that code, please step up now, not only when we're looking into
> > removing that code for good.
>
> Which drivers and what support? I see Kyösti Mälkki replied with better
> questions. Where is the biggest pain point today, i.e. not already being
> worked on and would return the most value to Coreboot by my work?
> _______________________________________________
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-leave@coreboot.org
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org