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"
"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.
On Thu, Sep 12, 2019 at 9:46 AM awokd via coreboot
> 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(a)coreboot.org
> To unsubscribe send an email to coreboot-leave(a)coreboot.org