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