Kyösti,
your concern seems to be mostly about "why do this at all?" rather than "is this the right approach to do and integrate it?", so that's what I'm responding to here:
Patch Set 9:
I agree resource allocator to be very limited (MEM and PREFMEM particularly), yet I have not seen serious attemps of previously mentioned companies fixing it themselves or
I like to ask UEFI folks why they think they can build a better operating system than folks who do nothing but build operating systems. The same is true for us: Linux has a battle-proven resource allocator, and if you end up using that anyway, why not skip ours instead of doing everything twice?
Doesn't mean we should remove our allocator because it's still useful in situations where Linux is prohibitive (that's the difference between coreboot and UEFI: they demand you take the whole enchilada, no questions asked).
contracting anyone familiar with the subsystem to work on the topic.
Last I heard, Rudolf, who designed and wrote the latest instance of our allocator, is happy with his job and tied up with personal projects, so I don't think he's available for contract.
Please list your design requirements rather than saying "this is a requested feature by 4 companies". Is it only about the 32bit MMIO space or maybe also the some dozen milliseconds lost in ramstage probing for PCI devices that could never ever be present?
The requirement is to pursue the original vision of having a minimal piece of code that gets the hardware into a state that Linux can take over. Ron never went away from that goal, and he pursued it on and off over time.
We do all kind of nerdy things in our code base that satisfy some rather peculiar requirements (for example, we added the splashscreen code + jpeg decoder for a one-off demo to sell the idea of coreboot to stakeholders), and I fail to see why we should stop doing so.
Of course, any such hack still needs to fit in the system as a whole (most prominently: stay out of the way of users who don't use it), but that doesn't seem to be what you're arguing.
To view, visit change 36221. To unsubscribe, or for help writing mail filters, visit settings.