Dear Piotr,
Thank you for bringing up these issues.
Am 28.04.21 um 00:38 schrieb Piotr Król:
On 4/21/21 8:33 PM, Patrick Georgi via coreboot wrote:
In our leadership meeting[1] we discussed how we should deal with tree-wide changes (ranging from "new file header" to "some API is gone now"). The concern was that right now, anything can change at any time, making local development harder.
I already added some comment on gerrit: https://review.coreboot.org/c/coreboot/+/52576/comment/4033eba1_56d6eab5/
There have been a few ideas but nothing definite yet:
One idea was to declare some interfaces (e.g. those used by src/mainboards/**), with varying stability horizons (e.g. "only change right after a release"), or backward compatibility guarantees (although the details still seemed hazy on how that could work in practice.)
Initial point was related to long term development on fork, but based on changes proposed by Patrick I wanted to rise other concerns.
Any guarantees should have some anchor e.g. in release version. At this point we all agree that release points of coreboot are chosen arbitrarily and provide no quality or API compatibility guarantees. Despite it is clearly stated in documentation out of community not many people know that.
From embedded systems consulting perspective, and we faced applications of coreboot in e.g. trains or medical robots, long term support and some API compatibility is needed. Cost of massive rebase of patches from some old, or sometimes not so old, version may be not feasible - that's how some customers may get back to IBVs.
What worries me is that dislike of backward compatibility and easiness of throwing away "redundant" baggage of code that blocks tree-wide changes makes coreboot harder to maintain for long run in some applications.
This is one part of the problem, other is specifications compatibility where ACPI is one that breaks things often. coreboot moves with ACPI compiler faster then most of BSD systems, what lead to problems with BSD-based firewalls.
Please excuse my ignorance. I am still not fully understanding the problem, so it’d be great if more concrete examples could be given. For example, what ACPI change caused an OS problem?
I would have thought, that the “payload interface” and coreboot tables are the main problems.
Kind regards,
Paul