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
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
