Hi Denis,
On 04.01.23 17:33, Denis 'GNUtoo' Carikli wrote:> On Wed, 4 Jan 2023 04:37:01 +0100 (CET)
Martin Roth gaumless@tutanota.com wrote:
I think you're right that we need some way to guarantee that boards added to coreboot aren't going to be dropped again in a short period of time, but that requires investment from companies using coreboot to make sure that it happens.
The investment could also come from the people and organizations that want the boards to stay in Coreboot. My questions were mainly directed at trying to understand how much resources that would require to see if this is doable or not.
I believe the best investment can be made by the author/uploader of the chipset code, before and during review. AFAICT, the reason why individual platforms in the coreboot tree are treated very differently wrt. maintenance and deprecation is mostly because of very different levels of code quality.
Judging from the code I've seen that was moved away over the years, I guess review must have been more lax when that code was originally added. To mention only the latest revelation: The coreboot code to integrate AGESA apparently copied more code than necessary [1] from the previous, native K8 port. This was discovered only after a decade of cleaning that code up. If code is in such a state, nobody can fully understand it. And then naturally, nobody wants to touch it and adapt it when changing something at the heart of coreboot.
IMO, what you need if you want to ensure that platform support stays, is code that is readable and understandable. Tight code, that only does what is necessary is a bonus. Understanding the code should start at the uploader side. Copy-pasting, or reverting a code drop can't help there. If the uploader understands the code, it's easier to prepare it for review and there's a chance that the reviewer can understand it too and probably can help to make it even easier to be understood. If you get there, I'm sure, much fewer people would hesitate to keep the code up-to-date.
I've always estimated that it would take about $200k to get there for any of the older AMD platforms (assuming you can get experienced core- boot developers to do it). But once reasonable code for one platform would be written, the others should be a piece of cake in comparison.
There are people and organizations who want the Asus KGPE-D16 to continue to be supported in some form, so we are currently evaluating our options with that, with the constraint that the code needs to keep working over time. And upstream Coreboot is one of the options being evaluated.
A French association (Libre en Communs) already applied for funding through NLnet to bring The KGPE-D16 back to upstream Coreboot.
So if this is accepted, we will also need a plan to make sure that the board isn't removed again. And for that we'd need not only to review patches, but also to actually get work done so it doesn't get removed again.
So for instance we could get donations through an association to fund someone to keep the board supported, but to do that we do need to have at least a vague idea of the budget required for that.
I guess nobody can estimate the budget for that because it depends heavily on the state of the code when it would be re-added. I haven't followed up on the latest work around the fam15h support. Was it re- written or is it still based on the old, dropped code?
But to provide a rough idea: If the code was still in the state as it was when dropped, I'd say it's a full-time job to keep it main- tained.
When a chip is added to coreboot, how long is a company expected to maintain that chip in the coreboot repository? If we make it too short, nobody wants to develop mainboards for it. If we make that time too long, chip vendors aren't going to want to add their chips to the tree. I'm not sure how to balance that.
To keep supporting a given mainboard, I only know these options:
- Do like Linux and put the burden on people sending patches not to break the existing mainboards. This reduces the amount of work needed to maintain a given mainboard, but it still requires maintainers.
IMO this is the way to go. I'm convinced, if the initial investment is good enough, it can reduce the maintenance burden by orders of magnitude.
- Doing it like it's done now, putting most of the burden on people wanting to continue maintaining existing mainboards, but making it easier to cleanup code and add new mainboards.
It seems you are forgetting one group of people: those who want to actively continue coreboot. Same as Linux, we want to keep everything in the tree up to date. However, that's only possible if the code shows some degree of soundness. These people have carried most of the burden over the last years, AFAICT.
U-boot is probably somewhere in between both.
Another option would be to have different rules for different code quality. For instance require very good code quality (like Linux) for newer contributions, but also allow to rework very old code (like it's done now). This way at some point we'd end up with good code quality and we'd be able to follow the Linux model if people want to go this route.
AFAIK, Linux also has a staging area for unfortunate code. However, in case of the AGESA and fam15h platforms, I believe such code wouldn't even make it there. And once the code is in the upstream tree, it can affect everybody.
Another thought: Reworking old code of low quality often turns out to be much more expensive than writing new code. And new code usually comes with the bonus that at least the author understands it.
...
If so what are usually the factors taken into account? I assume that if there is too much change to do (like completely rewriting Coreboot in Rust), I assume that they won't be able to force a change like that on the rest of the Coreboot contributors. If that's the case it gives some indication of the amount of work required to convert to newer modules.
It also brings the question of what is taken into account when deciding to deprecate module X. For instance is the maintainability of each "modules" the only concern, or are the amount of supported mainboards and end users a concern too?
Is the amount of work needed to convert from module X to module X+1 taken into account? And is there usually some documentation that explains how to do the conversion? Or are do people need to find out by looking at the release notes and other boards being converted?
We don't currently have a written policy about it.
In that case, are the decisions justified somehow? If so we could just read them to understand what was taken into account.
And that work could probably be reused later on if one day people want to make a policy.
Beside the romcc issue that you already mentioned, I don't recall any change that was impossible to apply everywhere or needed much work to adapt all platforms. The actual burden usually was to get the platform code into a state that was meaningful enough to be adapted. For instance in one of the later cases, the allocator update: v4 was supposed to be a compatible replacement. Only bugs lurking in the individual platform code made the situation weird ;)
So, I wouldn't get too worked up about policies and documentation that only cover broken cases. Better focus on what can be done to avoid maintainability issues in the first place.
Nico