Hi Peter,
On 16.05.20 15:39, Peter Stuge wrote:
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.
I can't speak for Furquan or Google, but I can provide some insight why such work is necessary in general.
The traditional code is rather broken. I can't say if it was like this from the beginning (I didn't witness), or if it was broken later on. We have many workarounds throughout the code base to keep things running with this code. For instance, we assign all super-io resources manually. If we don't, the allocator tries to assign PCI resources in the narrow window of the super-io. I've traced this particular problem down once, and believe it was introduced about a decade ago. Probably also to pre- pare for 64-bit support. The history is full of half merged, failed attempts that were probably all wrong.
Support for legacy VGA resources on PCI is broken (we have it working now on modern systems that fully support 16-bit i/o decoding). There are also some hardcoded legacy i/o things that are just wrong.
The existing design also does not allow for bridges with multiple win- dows. One use case would be Intel's LPC bridges. Which we configure manually, mostly, but also got some (broken) code for newer Intel plat- forms (that conflicts with manually assigned resources).
I guess there are many more quirks that we already got used to and just don't see anymore. And yes, on top, some people wish for 64-bit support.
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.
Such an explanation would have been nice, I agree. But I also see a problem here: How to describe an algorithm that just doesn't make any sense? And if we'd make a mistake documenting the existing code, wouldn't that make it worse?
I'm not sure if Google is to blame here. They did some work, reviewed it, merged it. But they were also the first to push a revert. I think the big issue here is a communication issue that I see in the whole community. Nobody uses the mailing list anymore unless something breaks.
I would have wished for an announcement and that more people would have been invited for review. But apart from that, I don't see a reason to quarrel.
Nico