Indeed...
All I could find was "prepare for 64 bit resources". That is beyond weak.
To people dealing both with somewhat modern hardware and coreboot, it is well known that the resource allocator has a few crucial weaknesses in that area. See, for example,
review.coreboot.org/12575 which tried to merely work around the issue in 2015.
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.
That may belong in the commit message but certainly not in any comments in the tree.
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.
Have you looked at the type of contributions to the resource allocator in the last 2 years? Some fixes for sure but "significant contributions", not so much.
If anything this was because the allocator is a pretty hairy beast that nobody dared to come closer than strictly necessary. That seems to be the one unifying property of resource allocators by the way, given that the last rewrite had a similar genesis.
This is obviously the classic conflict between one strong contributor
working toward their special interest (enable particular future work)
Like allowing dGPUs that announce several gigs of on board RAM, or thunderbolt or USB4, yes. Highly special interests, indeed. (A few of them that Furquan's project doesn't even care about).
(do not break a working core algorithm).
I guess, if anything, you can complain to me about that: after all, I was the person who submitted that to master and who also held off on reverting it because I see value in getting that thing in.
We should not take for granted that our own stuff is the most important,
but rather the other way around.
I'd treat grandiose organizational psychoanalysis on public forums the same way but I guess everybody has their vice:
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. :\