Holy moly..
Furquan Shaikh wrote:
- Reland new allocator guarded by a Kconfig:
I looked at this and the original change.
It's nice that the new algorithm is well commented!
But I could not find any detailed explanation of the neccessity for touching much less *rewriting* this quite literally central piece of code in coreboot.
All I could find was "prepare for 64 bit resources". That is beyond weak.
Even worse, I also could not find any explanation of how the new algorithm is different from the old, neither in commit messages nor in comments.
I have to say that I am really amazed and apalled by this change.
I am so relieved that I don't invest heavily in coreboot anymore because I would be furious if I did, not to mention how I would feel if I had been contributing significantly to the existing, working algorithm.
Google, please consider what that means. Regardless of intentions, if you treat everyone else who contributes to the coreboot community with so little respect then you as a primary contributor set an atmosphere where others will not be respectful either. As a result, the project races to the bottom.
This is obviously the classic conflict between one strong contributor working toward their special interest (enable particular future work) and the larger coreboot community having a fundamentally different interest (do not break a working core algorithm).
In such situations, the strong contributor must always carry responsibility, and the responsible action in this case is to ensure that the new code is opt-in, not opt-out.
We should not take for granted that our own stuff is the most important, but rather the other way around.
I want to emphasize that I do not blame Furquan here, but Google the organization. This situation suggests to me that something isn't right in Google's coreboot team. The classic problem would be that there are some impossible (time) constraints, which just ends up being really toxic. :\
Kind regards
//Peter