Patch Set 9:
That's why I would like to hear from you, Ron, what is the goal
of this change? Is it about handing over control to the payload
with less resources assigned (what Jeremy asks for)? or is it
about scanning less to reduce boot times? or about doing less
in general? or something entirely else that I miss?
1) yes, it is about handing over control to the payload with less resources assigned. Why?
Because, in some cases, for some uses, coreboot is doing the wrong thing in the name of supporting all possible payloads.
The coreboot allocator does a very good job of setting things up so any payload works. To make that work, it has to assume that it may boot a 32-bit payload (Aaron pointed this out I believe). In some cases, that leads to restrictions that are causing trouble for system76 and, IIUC, 9elements. In my discussions with jeremy it became pretty clear that it would be better for them were coreboot not to do this allocation; further, it's no longer clear it is needed.
64-bit systems have always had problems, going back to the early 2000s and opteron. At Los Alamos we had issues when interfaces (like Quadrics) demanded a large fraction of the low 4G. It would have been simpler for us had coreboot not tried to continue supporting 32-bit constraints.
This is not a new problem. But it has not been an issue for anyone but me until the last 2 years or so.
2) Yes, it is about reducing boot times.
Intel got some pretty good numbers by reducing what coreboot is doing. I can let them speak to that but the performance was compelling.
3) yes, it is about doing less in general
I like systems that do as little as possible. If we can remove work, I think we should.
From an esthetic standpoint, on systems I know will boot 64-bit linux kernels in flash (i.e. what Google and facebook are rolling into their data centers today -- 64-bit linux kernels in flash) running the coreboot allocator no longer seems needed. The kernel nowadays has its own preferences about how to configure PCI, and it doesn't make a lot of sense for coreboot to do a bunch of work the kernel either will undo or would like to undo.
So that's it. I would guess there are more reasons, but these are the ones that I think answer your questions.
This discussion then splits into 2 questions:
1) do we ever see coreboot allowing this kind of change? On this answer hinges the future use of coreboot by those using it now. I.e., they might well decided they need to use something else.
2) If the change in this CL is not acceptable, what change can we make that mostly eliminates coreboot PCI scanning? Is the alternative Kyosti mentioned acceptable, for example? If not, what is?
To view, visit change 36221. To unsubscribe, or for help writing mail filters, visit settings.