Attention is currently required from: Martin Roth, Julius Werner, Felix Held. Piotr Król has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/52576 )
Change subject: Documentation: Add suggestion to document flag days ......................................................................
Patch Set 1:
(1 comment)
File Documentation/getting_started/gerrit_guidelines.md:
https://review.coreboot.org/c/coreboot/+/52576/comment/43193ffb_1f2c96a0 PS1, Line 332: requires a change in all mainboards using it) needs to be documented.
- Sign of life - certain string showing as early as possible on platform boot
Open to discussion but I think this might be reasonable as a Kconfig (depending on how complicated it looks).
It would be sent upstream for review and we will see.
- Experimental uCode inclusion
Is this more than just setting the microcode file Kconfig to some file you maintain out-of-tree? (I think that's considered supported.)
That seem to be the scope, but if you say it is supported for AMD we have to check that.
- ACPI difference, mentioned in email thread, required for OS compatibility
I haven't fully understood that problem, but generally, I think OS compatibility stuff is something that can be included upstream (depends on whether we're talking about a publicly available OS or something custom used only by your customer, maybe). Again, I think coreboot itself gets developed as a sort of monolithic blob with no stable boundaries on its inside, but the boundary between coreboot and the payload or the OS is different and we spend more effort trying to keep that as stable and widely compatible as possible.
We talking about BSD and its downstream distros eg. pfSense or OPNsense, which are important for firewall customers. Those distros typically do not use bleeding edge version of ACPI.
Maybe we should be clear about saying that coreboot is too expensive for small OEM/ODM, they should go to IBVs.
I don't think anyone is trying to build any intentional barriers here to keep someone out. We're all interested in making all the things that people want to do with coreboot as cheap and easy as possible. I just don't think there are any easy answers to your problems here. "Everyone stop making big API changes" isn't something we can do, then we can't really develop big new features at all anymore. Then the project would basically become irrelevant and die out. "Spend a ton of extra effort on every global change you make" also becomes prohibitive and will effectively cause the same problems as forbidding big changes completely. I think we can discuss smaller effort process changes (e.g. writing spatches where it makes sense), but it needs to balance out the effort saved on one side and the extra effort caused on the other.
Agree. I just brought 3mdeb perspective to discussion. We hope that continuation of discussed strategies will not eventually push out less-resourceful players out of tree.
-
Piotr Król (Code Review)