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