Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hi I would like to suggest to deprecate some legacy codepaths inside the coreboot tree and therefore make some newer ones mandatory. The first one I'd like to deprecate is LEGACY_SMP_INIT. This also includes the codepath for SMM_ASEG. This code is used to start APs and do some feature programming on each AP, but also set up SMM. This has largely been superseded by PARALLEL_MP, which should be able to cover all use cases of LEGACY_SMP_INIT, with little code changes. The reason for deprecation is that having 2 codepaths to do the virtually the same increases maintenance burden on the community a lot, while also being rather confusing. A few things are lacking in PARALLEL_MP init: - Support for !CONFIG_SMP on single core systems. It's likely easy to extend PARALLEL_MP or write some code that just does CPU detection on the BSP CPU. - Support smm in the legacy ASEG (0xa0000 - 0xb0000) region. A POC showed that it's not that hard to do with PARALLEL_MP https://review.coreboot.org/c/coreboot/+/58700 No platforms in the tree have any hardware limitations that would block migrating to PARALLEL_MP / a simple !CONFIG_SMP codebase. The second codepath that I'd like to propose for deprecation is RESOURCE_ALLOCATOR_V3. V4 was introduced more than a year ago and with minor changes most platforms were able to work just fine with it. A major difference is that V3 uses just one continuous region below 4G to allocate all PCI memory BAR's. V4 uses all available space below 4G and if asked to, also above 4G too. This makes it important that SoC code properly reports all fixed resources. Currently only AGESA platforms have issues with it. On gerrit both attempts to fix AMD AGESA codebases to use V4 and compatibility modes inside the V4 allocator have been proposed, but both efforts seem stalled. See the (not yet merged) documentation https://review.coreboot.org/c/coreboot/+/43603 on it's details. It looks like properly reporting all fixed resources is the culprit. About the timeline of deprecations. Is deprecating non conforming platforms from the master branch after the 4.16 release in 6 months a reasonable proposal? The affected boards currently are: AMD_INAGUA AMD_OLIVEHILL AMD_PARMER AMD_SOUTHSTATION AOPEN_DXPLPLUSU AMD_PERSIMMON AMD_THATCHER AMD_UNIONSTATION ASROCK_E350M1 ASUS_A88XM_E ASROCK_IMB_A180 ASUS_AM1I_A ASUS_F2A85_M ASUS_F2A85_M_PRO ASUS_F2A85_M_LE ASUS_P2B_RAMDEBUG ASUS_P2B_LS ASUS_P2B_F ASUS_P2B_D ASUS_P2B_DS ASUS_P3B_F ASUS_P2B ODE_E20XX BIOSTAR_AM1ML BIOSTAR_A68N5200 ELMEX_PCM205400 ELMEX_PCM205401 GIZMOSPHERE_GIZMO2 GIZMOSPHERE_GIZMO HP_ABM HP_PAVILION_M6_1035DX JETWAY_NF81_T56N_LF LENOVO_G505S LIPPERT_FRONTRUNNER_AF LIPPERT_TOUCAN_AF MSI_MS7721 PCENGINES_APU1_ PCENGINES_APU2_ PCENGINES_APU3_ PCENGINES_APU4_ PCENGINES_APU5_ PCENGINES_APU1 PCENGINES_APU2 PCENGINES_APU3 PCENGINES_APU4 PCENGINES_APU5 sidenote: Qemu platforms support both LEGACY_SMP_INIT and PARALLEL_MP init so I did not list them here. Let me know your thoughts. Arthur
I think, given how good a job you've all done with the release tags and so on, it's easy for people to get to a working build for a board; therefore, deprecating non conforming platforms make sense, as does your suggestion for six months. On Wed, Nov 24, 2021 at 4:51 AM Arthur Heymans <arthur@aheymans.xyz> wrote:
Hi
I would like to suggest to deprecate some legacy codepaths inside the coreboot tree and therefore make some newer ones mandatory.
The first one I'd like to deprecate is LEGACY_SMP_INIT. This also includes the codepath for SMM_ASEG. This code is used to start APs and do some feature programming on each AP, but also set up SMM. This has largely been superseded by PARALLEL_MP, which should be able to cover all use cases of LEGACY_SMP_INIT, with little code changes. The reason for deprecation is that having 2 codepaths to do the virtually the same increases maintenance burden on the community a lot, while also being rather confusing.
A few things are lacking in PARALLEL_MP init: - Support for !CONFIG_SMP on single core systems. It's likely easy to extend PARALLEL_MP or write some code that just does CPU detection on the BSP CPU. - Support smm in the legacy ASEG (0xa0000 - 0xb0000) region. A POC showed that it's not that hard to do with PARALLEL_MP https://review.coreboot.org/c/coreboot/+/58700
No platforms in the tree have any hardware limitations that would block migrating to PARALLEL_MP / a simple !CONFIG_SMP codebase.
The second codepath that I'd like to propose for deprecation is RESOURCE_ALLOCATOR_V3. V4 was introduced more than a year ago and with minor changes most platforms were able to work just fine with it. A major difference is that V3 uses just one continuous region below 4G to allocate all PCI memory BAR's. V4 uses all available space below 4G and if asked to, also above 4G too. This makes it important that SoC code properly reports all fixed resources.
Currently only AGESA platforms have issues with it. On gerrit both attempts to fix AMD AGESA codebases to use V4 and compatibility modes inside the V4 allocator have been proposed, but both efforts seem stalled. See the (not yet merged) documentation https://review.coreboot.org/c/coreboot/+/43603 on it's details. It looks like properly reporting all fixed resources is the culprit.
About the timeline of deprecations. Is deprecating non conforming platforms from the master branch after the 4.16 release in 6 months a reasonable proposal?
The affected boards currently are: AMD_INAGUA AMD_OLIVEHILL AMD_PARMER AMD_SOUTHSTATION AOPEN_DXPLPLUSU AMD_PERSIMMON AMD_THATCHER AMD_UNIONSTATION ASROCK_E350M1 ASUS_A88XM_E ASROCK_IMB_A180 ASUS_AM1I_A ASUS_F2A85_M ASUS_F2A85_M_PRO ASUS_F2A85_M_LE ASUS_P2B_RAMDEBUG ASUS_P2B_LS ASUS_P2B_F ASUS_P2B_D ASUS_P2B_DS ASUS_P3B_F ASUS_P2B ODE_E20XX BIOSTAR_AM1ML BIOSTAR_A68N5200 ELMEX_PCM205400 ELMEX_PCM205401 GIZMOSPHERE_GIZMO2 GIZMOSPHERE_GIZMO HP_ABM HP_PAVILION_M6_1035DX JETWAY_NF81_T56N_LF LENOVO_G505S LIPPERT_FRONTRUNNER_AF LIPPERT_TOUCAN_AF MSI_MS7721 PCENGINES_APU1_ PCENGINES_APU2_ PCENGINES_APU3_ PCENGINES_APU4_ PCENGINES_APU5_ PCENGINES_APU1 PCENGINES_APU2 PCENGINES_APU3 PCENGINES_APU4 PCENGINES_APU5
sidenote: Qemu platforms support both LEGACY_SMP_INIT and PARALLEL_MP init so I did not list them here.
Let me know your thoughts.
Arthur
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hey Arthur, Nov 24, 2021, 05:50 by arthur@aheymans.xyz:
Hi I would like to suggest to deprecate some legacy codepaths inside the coreboot tree and therefore make some newer ones mandatory. ... snip ...> About the timeline of deprecations. Is deprecating non conforming platforms from the master branch after the 4.16 release in 6 months a reasonable proposal?
I have no strong opinion about the platform deprecations, although I suspect that PC Engines might be unhappy if it's platforms were removed from the ToT codebase. My preference would be to announce deprecations in the release notes. We just missed the 4.15 release, but we're switching to a 3 month release cadence, so the next release will be in early February, 2.5 months from now. We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch. Would this schedule work? Martin
We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
That timeline of 8.5 months does sound fair. I just found this updated release schedule in the meeting minutes. If we are going to release every 3 months then I guess that's a good way to go. I started a CL: https://review.coreboot.org/c/coreboot/+/59618 . I'll update it to reflect that schedule if it can be agreed upon. On Wed, Nov 24, 2021 at 6:07 PM Martin Roth <gaumless@tutanota.com> wrote:
Hey Arthur,
Nov 24, 2021, 05:50 by arthur@aheymans.xyz:
Hi I would like to suggest to deprecate some legacy codepaths inside the coreboot tree and therefore make some newer ones mandatory. ... snip ...> About the timeline of deprecations. Is deprecating non conforming platforms from the master branch after the 4.16 release in 6 months a reasonable proposal?
I have no strong opinion about the platform deprecations, although I suspect that PC Engines might be unhappy if it's platforms were removed from the ToT codebase.
My preference would be to announce deprecations in the release notes. We just missed the 4.15 release, but we're switching to a 3 month release cadence, so the next release will be in early February, 2.5 months from now.
We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
Would this schedule work?
Martin
With all due respect, dropping support for the majority of AMD boards - with a quite significant community around them! - doesn't seem like a wise decision, if we still care about the coreboot marketshare on the worldwide-available consumer PCs. Small improvement in the common source, but a huge loss of boards? (almost 50!). For the sake of the bright future of the coreboot project, this must be prevented at all costs... Some time ago I did https://review.coreboot.org/c/coreboot/+/41431 change where tried to get a resource allocator V4 working for these AGESA boards, and despite a tiny size (less than 20 lines) - it almost worked, judging by that fam15h A88XM-E booted fine (although there might have been some other problems undercover). I wonder if it could help and will be happy to test the new changes related to this. On Wed, Nov 24, 2021 at 8:52 PM Arthur Heymans <arthur@aheymans.xyz> wrote:
We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
That timeline of 8.5 months does sound fair. I just found this updated release schedule in the meeting minutes. If we are going to release every 3 months then I guess that's a good way to go.
I started a CL: https://review.coreboot.org/c/coreboot/+/59618 . I'll update it to reflect that schedule if it can be agreed upon.
On Wed, Nov 24, 2021 at 6:07 PM Martin Roth <gaumless@tutanota.com> wrote:
Hey Arthur,
Nov 24, 2021, 05:50 by arthur@aheymans.xyz:
Hi I would like to suggest to deprecate some legacy codepaths inside the coreboot tree and therefore make some newer ones mandatory. ... snip ...> About the timeline of deprecations. Is deprecating non conforming platforms from the master branch after the 4.16 release in 6 months a reasonable proposal?
I have no strong opinion about the platform deprecations, although I suspect that PC Engines might be unhappy if it's platforms were removed from the ToT codebase.
My preference would be to announce deprecations in the release notes. We just missed the 4.15 release, but we're switching to a 3 month release cadence, so the next release will be in early February, 2.5 months from now.
We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
Would this schedule work?
Martin
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
With all due respect, dropping support for the majority of AMD boards - with a quite significant community around them! - doesn't seem like a wise decision, if we still care about the coreboot marketshare on the worldwide-available consumer PCs. Small improvement in the common source, but a huge loss of boards? (almost 50!). For the sake of the bright future of the coreboot project, this must be prevented at all costs...
If there is such a community around those boards there must be someone willing to either invest time or money to implement the proposed improvements. Having boards or platforms inside the tree is much cheaper than paying AMI for a crappy closed source BIOS/UEFI. It's still not a free endeavor and code requires maintenance from time to time such that development on the master branch can remain simple and sensible. Not maintaining code from time to time and enforcing some features, is probably far worse for the project.
Some time ago I did https://review.coreboot.org/c/coreboot/+/41431 change where tried to get a resource allocator V4 working for these AGESA boards, and despite a tiny size (less than 20 lines) - it almost worked, judging by that fam15h A88XM-E booted fine (although there might have been some other problems undercover). I wonder if it could help and will be happy to test the new changes related to this.
The proposed change requires the code to know what memory regions are used and must be reserved. Angel already reviewed the patch it seems, so that's probably a good start. On Wed, Nov 24, 2021 at 9:16 PM Mike Banon <mikebdp2@gmail.com> wrote:
With all due respect, dropping support for the majority of AMD boards - with a quite significant community around them! - doesn't seem like a wise decision, if we still care about the coreboot marketshare on the worldwide-available consumer PCs. Small improvement in the common source, but a huge loss of boards? (almost 50!). For the sake of the bright future of the coreboot project, this must be prevented at all costs...
Some time ago I did https://review.coreboot.org/c/coreboot/+/41431 change where tried to get a resource allocator V4 working for these AGESA boards, and despite a tiny size (less than 20 lines) - it almost worked, judging by that fam15h A88XM-E booted fine (although there might have been some other problems undercover). I wonder if it could help and will be happy to test the new changes related to this.
On Wed, Nov 24, 2021 at 8:52 PM Arthur Heymans <arthur@aheymans.xyz> wrote:
We could announce this deprecation in the 4.16 release notes, then
deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
That timeline of 8.5 months does sound fair. I just found this updated
release schedule in the meeting minutes.
If we are going to release every 3 months then I guess that's a good way to go.
I started a CL: https://review.coreboot.org/c/coreboot/+/59618 . I'll update it to reflect that schedule if it can be agreed upon.
On Wed, Nov 24, 2021 at 6:07 PM Martin Roth <gaumless@tutanota.com> wrote:
Hey Arthur,
Nov 24, 2021, 05:50 by arthur@aheymans.xyz:
Hi I would like to suggest to deprecate some legacy codepaths inside the
coreboot tree and therefore make some newer ones mandatory.
... snip ...> About the timeline of deprecations. Is deprecating non conforming platforms from the master branch after the 4.16 release in 6 months a reasonable proposal?
I have no strong opinion about the platform deprecations, although I suspect that PC Engines might be unhappy if it's platforms were removed from the ToT codebase.
My preference would be to announce deprecations in the release notes. We just missed the 4.15 release, but we're switching to a 3 month release cadence, so the next release will be in early February, 2.5 months from now.
We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
Would this schedule work?
Martin
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
The word 'drop' has ominous connotations, but it's not a deletion. A board is never really gone. It's git. I can still find the Alpha boards in there if I go back far enough. It's just that active development ends, as no one is working to keep them up to date. Would it be ok with you to drop the board, and bring it back when it is working again? There is a cost to keeping boards too long when there is no one maintaining them. They may still build, but they can stop working. That's happened and in my view it's best not to let it happen. People should be able to count on a board working if they build an image. Thanks ron On Wed, Nov 24, 2021 at 12:16 PM Mike Banon <mikebdp2@gmail.com> wrote:
With all due respect, dropping support for the majority of AMD boards - with a quite significant community around them! - doesn't seem like a wise decision, if we still care about the coreboot marketshare on the worldwide-available consumer PCs. Small improvement in the common source, but a huge loss of boards? (almost 50!). For the sake of the bright future of the coreboot project, this must be prevented at all costs...
Some time ago I did https://review.coreboot.org/c/coreboot/+/41431 change where tried to get a resource allocator V4 working for these AGESA boards, and despite a tiny size (less than 20 lines) - it almost worked, judging by that fam15h A88XM-E booted fine (although there might have been some other problems undercover). I wonder if it could help and will be happy to test the new changes related to this.
On Wed, Nov 24, 2021 at 8:52 PM Arthur Heymans <arthur@aheymans.xyz> wrote:
We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
That timeline of 8.5 months does sound fair. I just found this updated release schedule in the meeting minutes. If we are going to release every 3 months then I guess that's a good way to go.
I started a CL: https://review.coreboot.org/c/coreboot/+/59618 . I'll update it to reflect that schedule if it can be agreed upon.
On Wed, Nov 24, 2021 at 6:07 PM Martin Roth <gaumless@tutanota.com> wrote:
Hey Arthur,
Nov 24, 2021, 05:50 by arthur@aheymans.xyz:
Hi I would like to suggest to deprecate some legacy codepaths inside the coreboot tree and therefore make some newer ones mandatory. ... snip ...> About the timeline of deprecations. Is deprecating non conforming platforms from the master branch after the 4.16 release in 6 months a reasonable proposal?
I have no strong opinion about the platform deprecations, although I suspect that PC Engines might be unhappy if it's platforms were removed from the ToT codebase.
My preference would be to announce deprecations in the release notes. We just missed the 4.15 release, but we're switching to a 3 month release cadence, so the next release will be in early February, 2.5 months from now.
We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
Would this schedule work?
Martin
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
The word 'drop' has ominous connotations, but it's not a deletion. A board is never really gone.
"Dropping" 50 boards may be ominous in relation to the future of the coreboot project: 1. These boards will be gone for the people who check the "mainboards supported by coreboot" and see only the "new Intel stuff". This hinders the coreboot community growth around the "gone boards", and also of the coreboot community in general: the fewer boards are supported by coreboot, the more difficult it is for a potential user/contributor to find the supported board and join us. 2. It's not just the loss of boards - it's also the loss of coreboot users/contributors who only have these boards and don't want to switch to anything else: i.e. because the newer coreboot-supported boards have Intel ME / AMD PSP that are viewed negatively by many people out of security considerations, - and security is one of the top reasons why the people switch to coreboot in the first place. 3. Unless someone will be manually copying all the time, these boards won't get the updates of the common coreboot parts, even if such updates aren't related to the deletion reason. A reason which won't be understood by the opensource-loving community around the world - on Phoronix etc. - as good enough for "50 boards drop" - so doing this may harm the reputation of a coreboot project. Of course, the people may finally fork a coreboot to i.e. "coreboot_extended" or "coreboot_notcorporate" (need a good name) and continue contributing there. Such a fork may even become more popular than the original coreboot of the future, because it will support significantly more boards. But, if this happens, it will fragment the coreboot community and split / spread thin our joint efforts for not a good enough reason.
It's just that active development ends, as no one is working to keep them up to date. There is a cost to keeping boards too long when there is no one maintaining them.
Even right now there's an active development & maintainership (as evidenced by all these changes at review.coreboot.org), - just not for this v4 resource allocator.
Would it be ok with you to drop the board, and bring it back when it is working again?
I'm not sure I understand: at least my boards from this list are working perfectly at the moment.
They may still build, but they can stop working. People should be able to count on a board working if they build an image.
I am often build-testing my boards (didn't notice a https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but only because I've been re-using the previously built toolchains to save time). Also, I am actively tech-supporting all the people who would like to build coreboot for AMD boards from this list, even right now I am in an active message exchange with >10 people who are switching to these boards to run coreboot on them - and any user may give back to the project one day. Hopefully my post above explains why I think "dropping 50 boards is a bad idea", although I agree that it would be nice to get a resource allocator v4 working on them. On Thu, Nov 25, 2021 at 12:46 AM ron minnich <rminnich@gmail.com> wrote:
The word 'drop' has ominous connotations, but it's not a deletion. A board is never really gone. It's git. I can still find the Alpha boards in there if I go back far enough. It's just that active development ends, as no one is working to keep them up to date.
Would it be ok with you to drop the board, and bring it back when it is working again?
There is a cost to keeping boards too long when there is no one maintaining them. They may still build, but they can stop working. That's happened and in my view it's best not to let it happen. People should be able to count on a board working if they build an image.
Thanks
ron
On Wed, Nov 24, 2021 at 12:16 PM Mike Banon <mikebdp2@gmail.com> wrote:
With all due respect, dropping support for the majority of AMD boards - with a quite significant community around them! - doesn't seem like a wise decision, if we still care about the coreboot marketshare on the worldwide-available consumer PCs. Small improvement in the common source, but a huge loss of boards? (almost 50!). For the sake of the bright future of the coreboot project, this must be prevented at all costs...
Some time ago I did https://review.coreboot.org/c/coreboot/+/41431 change where tried to get a resource allocator V4 working for these AGESA boards, and despite a tiny size (less than 20 lines) - it almost worked, judging by that fam15h A88XM-E booted fine (although there might have been some other problems undercover). I wonder if it could help and will be happy to test the new changes related to this.
On Wed, Nov 24, 2021 at 8:52 PM Arthur Heymans <arthur@aheymans.xyz> wrote:
We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
That timeline of 8.5 months does sound fair. I just found this updated release schedule in the meeting minutes. If we are going to release every 3 months then I guess that's a good way to go.
I started a CL: https://review.coreboot.org/c/coreboot/+/59618 . I'll update it to reflect that schedule if it can be agreed upon.
On Wed, Nov 24, 2021 at 6:07 PM Martin Roth <gaumless@tutanota.com> wrote:
Hey Arthur,
Nov 24, 2021, 05:50 by arthur@aheymans.xyz:
Hi I would like to suggest to deprecate some legacy codepaths inside the coreboot tree and therefore make some newer ones mandatory. ... snip ...> About the timeline of deprecations. Is deprecating non conforming platforms from the master branch after the 4.16 release in 6 months a reasonable proposal?
I have no strong opinion about the platform deprecations, although I suspect that PC Engines might be unhappy if it's platforms were removed from the ToT codebase.
My preference would be to announce deprecations in the release notes. We just missed the 4.15 release, but we're switching to a 3 month release cadence, so the next release will be in early February, 2.5 months from now.
We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
Would this schedule work?
Martin
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
On 25.11.21 17:04, Mike Banon <mikebdp2@gmail.com> wrote:
2. It's not just the loss of boards - it's also the loss of coreboot users/contributors who only have these boards and don't want to switch These users didn't contribute fixes to their boards (or even just feedback that things needs to be done and testing when others provide patches) - are they even contributors?
It's easy to argue in favor of "lots of users" (or contributors if you want), but if they're all but invisible, do they even exist?
Of course, the people may finally fork a coreboot to i.e. Do it. I'm getting tired of people making this particular empty promise.
"coreboot_extended" or "coreboot_notcorporate" (need a good name) and Given this:
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
Maybe coreboot_3mdeb_corporate might be a proper name? Regards, Patrick
On November 25, 2021 4:43:35 PM UTC, Patrick Georgi via coreboot <coreboot@coreboot.org> wrote:
On 25.11.21 17:04, Mike Banon <mikebdp2@gmail.com> wrote: These users didn't contribute fixes to their boards (or even just feedback that things needs to be done and testing when others provide patches) - are they even contributors?
It's easy to argue in favor of "lots of users" (or contributors if you want), but if they're all but invisible, do they even exist?
I'm one of that invisible contributors. In my opinion coreboot is more developer friendly than user friendly. For me not since I get use to coreboot builds at some point in time. But in general coreboot is hard to get your hands on at first. And board depreciation is not a good idea. I understand that they can be brought back at some point. But lets be realistic that this need some developer time and testing. And in capitalistic world that means money to support old boards. I just hope I am wrong...
Am 25.11.2021 um 18:06 schrieb AreYouLoco? via coreboot:
In my opinion coreboot is more developer friendly than user friendly. Kinda obvious: We don't even ship binaries...
Given the trouble these deprecation announcements always are, I can tell you an even more developer friendly strategy: We could simply make all boards compile _somehow_ with the new infrastructure and retire the old one because it fell out of use. Without telling anybody. If such a change lands in, say 4.16, and you only think of updating your firmware in, say 4.20, there has been one year of development going on after the removal (assuming the newly-proposed quarterly release schedule). The result: fixing the issue becomes much harder, by then, rolling back is impossible, and nobody can quite remember what the issue was. That strategy is more developer friendly because we don't have to deal with crap on the mailing list. Is it more user friendly?
And board depreciation is not a good idea. I understand that they can be brought back at some point. But lets be realistic that this need some developer time and testing. And in capitalistic world that means money to support old boards. It also costs developer time to keep maintaining several alternate code paths, some of which are only used for boards no developer still uses (or they would have patched them to use the new code already).
As it stands, the proposed timeline allows for: - ~2 more months to intervene before that list of boards even makes it into some official release notes. Adapt a board to the new infrastructure before then and it can disappear from that list before it even becomes official. - 6 additional months in which the announcement is out in the open but the code is still in ToT. Adapt a board to the new infrastructure before then and while the old infrastructure will be dropped, the board won't be affected. Even after that, all the existing coreboot versions are still there. There are already some patches out there, so it appears that the strategy how to adapt a board to the new infrastructure is well understood - we're lacking the ability to test these boards. Even if you can't adapt a board yourself, I'd suspect that announcing that you have some piece of hardware, can provide logs and offer to run tests will spark interest in developers creating a patch for the board. We just don't do that speculatively because while it's usually simple to make a board compile it's far from clear that the result will still boot. So: what board(s) are you offering to test? Patrick
Dear coreboot folks, Am 25.11.21 um 17:43 schrieb Patrick Georgi:
On 25.11.21 17:04, Mike Banon wrote:
[…] [ forking threat, and follow-up comment ] Please let’s not escalate this. (Type your answer, save it in the draft folder, sleep over it, and then think if you want to send it.) I thank Arthur, for bringing this up on the list. 8.5 months is hopefully enough to review the 3mdeb patches [1] and maybe even Nico’s proposed allocator improvements [2]. Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/53991 "cpu/amd/agesa/family15tn/model_15_init.c: create correct MTRR solution" [2]: https://review.coreboot.org/c/coreboot/+/41956 "device: Introduce v4.5 resource allocator"
Patrick Georgi via coreboot:
On 25.11.21 17:04, Mike Banon <mikebdp2@gmail.com> wrote:
2. It's not just the loss of boards - it's also the loss of coreboot users/contributors who only have these boards and don't want to switch These users didn't contribute fixes to their boards (or even just feedback that things needs to be done and testing when others provide patches) - are they even contributors?
It's easy to argue in favor of "lots of users" (or contributors if you want), but if they're all but invisible, do they even exist?
I contributed a number of changes to address Coverity warnings in the AMD families, and am actively using a corebooted G505s and PC Engines APU. I lurk in the mailing list most of the time, and have a hard time tracking what needs to be done to keep boards alive. On this thread, for example, the updated requirements feel like they are (but are likely not) coming out of the blue. To address the OP, it seems like there is some activity on getting an AGESA RESOURCE_ALLOCATOR_V4 working, but is an AGESA PARALLEL_MP init also needed (and is there any activity or something I can do to help?) Realize resources may not exist to spoon feed problem definitions to a level my brain can handle. The rest of the reply might be due to communication losses of non-face to face transmission medium.
To address the OP, it seems like there is some activity on getting an AGESA RESOURCE_ALLOCATOR_V4 working, but is an AGESA PARALLEL_MP init also needed (and is there any activity or something I can do to help?) Realize resources may not exist to spoon feed problem definitions to a level my brain can handle.
https://review.coreboot.org/c/coreboot/+/48210 and https://review.coreboot.org/c/coreboot/+/48262/ provided the implementation for PARALLEL_MP on qemu. Notice that modern AMD CPUs (soc/amd/¨*) also use PARALLEL_MP and can be used as an example for AMD AGESA platforms too. Good luck! Arthur On Thu, Nov 25, 2021 at 6:30 PM awokd via coreboot <coreboot@coreboot.org> wrote:
Patrick Georgi via coreboot:
On 25.11.21 17:04, Mike Banon <mikebdp2@gmail.com> wrote:
2. It's not just the loss of boards - it's also the loss of coreboot users/contributors who only have these boards and don't want to switch These users didn't contribute fixes to their boards (or even just feedback that things needs to be done and testing when others provide patches) - are they even contributors?
It's easy to argue in favor of "lots of users" (or contributors if you want), but if they're all but invisible, do they even exist?
I contributed a number of changes to address Coverity warnings in the AMD families, and am actively using a corebooted G505s and PC Engines APU. I lurk in the mailing list most of the time, and have a hard time tracking what needs to be done to keep boards alive. On this thread, for example, the updated requirements feel like they are (but are likely not) coming out of the blue.
To address the OP, it seems like there is some activity on getting an AGESA RESOURCE_ALLOCATOR_V4 working, but is an AGESA PARALLEL_MP init also needed (and is there any activity or something I can do to help?) Realize resources may not exist to spoon feed problem definitions to a level my brain can handle.
The rest of the reply might be due to communication losses of non-face to face transmission medium. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Arthur Heymans:
https://review.coreboot.org/c/coreboot/+/48210 and https://review.coreboot.org/c/coreboot/+/48262/ provided the implementation for PARALLEL_MP on qemu. Notice that modern AMD CPUs (soc/amd/¨*) also use PARALLEL_MP and can be used as an example for AMD AGESA platforms too.
Good luck!
Thank you, going to need it! Would be nice if that AMD open source rep. wanted to own and deliver on global (to AMD AGESA) changes like this to "demonstrate a renewed commitment to the community" in corpospeak, but will see what I can do. Do you remember from where you got these magic values? Suspect I'm going to need similar. Will investigate soc/amd/¨* too. /* QEMU-specific register */ #define EXT_TSEG_MBYTES 0x50 +#define SMRAMC 0x9d +#define C_BASE_SEG ((0 << 2) | (1 << 1) | (0 << 0)) +#define G_SMRAME (1 << 3) +#define D_LCK (1 << 4) +#define D_CLS (1 << 5) +#define D_OPEN (1 << 6) +#define ESMRAMC 0x9e +#define T_EN (1 << 0) +#define TSEG_SZ_MASK (3 << 1) +#define H_SMRAME (1 << 7)
Do you remember from where you got these magic values? Suspect I'm going to need similar. Will investigate soc/amd/¨* too.
/* QEMU-specific register */ #define EXT_TSEG_MBYTES 0x50 +#define SMRAMC 0x9d +#define C_BASE_SEG ((0 << 2) | (1 << 1) | (0 << 0)) +#define G_SMRAME (1 << 3) +#define D_LCK (1 << 4) +#define D_CLS (1 << 5) +#define D_OPEN (1 << 6) +#define ESMRAMC 0x9e +#define T_EN (1 << 0) +#define TSEG_SZ_MASK (3 << 1) +#define H_SMRAME (1 << 7)
Those are northbridge specific register on how to handle the SMM windows (SMRAM). The BKDG should have something similar. TSEG is also an interesting search parameter. On Thu, Nov 25, 2021 at 7:39 PM awokd via coreboot <coreboot@coreboot.org> wrote:
Arthur Heymans:
https://review.coreboot.org/c/coreboot/+/48210 and https://review.coreboot.org/c/coreboot/+/48262/ provided the implementation for PARALLEL_MP on qemu. Notice that modern AMD CPUs (soc/amd/¨*) also use PARALLEL_MP and can be used as an example for AMD AGESA platforms too.
Good luck!
Thank you, going to need it! Would be nice if that AMD open source rep. wanted to own and deliver on global (to AMD AGESA) changes like this to "demonstrate a renewed commitment to the community" in corpospeak, but will see what I can do.
Do you remember from where you got these magic values? Suspect I'm going to need similar. Will investigate soc/amd/¨* too.
/* QEMU-specific register */ #define EXT_TSEG_MBYTES 0x50 +#define SMRAMC 0x9d +#define C_BASE_SEG ((0 << 2) | (1 << 1) | (0 << 0)) +#define G_SMRAME (1 << 3) +#define D_LCK (1 << 4) +#define D_CLS (1 << 5) +#define D_OPEN (1 << 6) +#define ESMRAMC 0x9e +#define T_EN (1 << 0) +#define TSEG_SZ_MASK (3 << 1) +#define H_SMRAME (1 << 7) _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
1. These boards will be gone for the people who check the "mainboards supported by coreboot" and see only the "new Intel stuff". This hinders the coreboot community growth around the "gone boards", and also of the coreboot community in general: the fewer boards are supported by coreboot, the more difficult it is for a potential user/contributor to find the supported board and join us.
Coreboot supports a lot more platforms than "new Intel stuff", which is quite an achievement. To make it possible for very different hardware in one branch, thoughtful design is needed. Supporting different codepaths to do the same thing blows up the complexity of maintenance and makes it harder to support both old and new boards as you lose track of how code changes can affect other systems. Keeping things simple is not optional in a project like coreboot. So it's not about adding a minor feature like you said in your previous email. It's really about keeping things manageable long term for everyone. That however requires some work from time to time on some platforms and sometimes dropping boards if no one steps up to do that work.
2. It's not just the loss of boards - it's also the loss of coreboot users/contributors who only have these boards and don't want to switch to anything else: i.e. because the newer coreboot-supported boards have Intel ME / AMD PSP that are viewed negatively by many people out of security considerations, - and security is one of the top reasons why the people switch to coreboot in the first place.
Sorry, not buying that argument at all for AMD AGESA supported platforms. I don't see a lot of development on gerrit for these platforms especially in comparison with Intel ones of similar age. Regards Arthur On Thu, Nov 25, 2021 at 5:04 PM Mike Banon <mikebdp2@gmail.com> wrote:
The word 'drop' has ominous connotations, but it's not a deletion. A board is never really gone.
"Dropping" 50 boards may be ominous in relation to the future of the coreboot project:
1. These boards will be gone for the people who check the "mainboards supported by coreboot" and see only the "new Intel stuff". This hinders the coreboot community growth around the "gone boards", and also of the coreboot community in general: the fewer boards are supported by coreboot, the more difficult it is for a potential user/contributor to find the supported board and join us.
2. It's not just the loss of boards - it's also the loss of coreboot users/contributors who only have these boards and don't want to switch to anything else: i.e. because the newer coreboot-supported boards have Intel ME / AMD PSP that are viewed negatively by many people out of security considerations, - and security is one of the top reasons why the people switch to coreboot in the first place.
3. Unless someone will be manually copying all the time, these boards won't get the updates of the common coreboot parts, even if such updates aren't related to the deletion reason. A reason which won't be understood by the opensource-loving community around the world - on Phoronix etc. - as good enough for "50 boards drop" - so doing this may harm the reputation of a coreboot project.
Of course, the people may finally fork a coreboot to i.e. "coreboot_extended" or "coreboot_notcorporate" (need a good name) and continue contributing there. Such a fork may even become more popular than the original coreboot of the future, because it will support significantly more boards. But, if this happens, it will fragment the coreboot community and split / spread thin our joint efforts for not a good enough reason.
It's just that active development ends, as no one is working to keep them up to date. There is a cost to keeping boards too long when there is no one maintaining them.
Even right now there's an active development & maintainership (as evidenced by all these changes at review.coreboot.org), - just not for this v4 resource allocator.
Would it be ok with you to drop the board, and bring it back when it is working again?
I'm not sure I understand: at least my boards from this list are working perfectly at the moment.
They may still build, but they can stop working. People should be able to count on a board working if they build an image.
I am often build-testing my boards (didn't notice a https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but only because I've been re-using the previously built toolchains to save time). Also, I am actively tech-supporting all the people who would like to build coreboot for AMD boards from this list, even right now I am in an active message exchange with >10 people who are switching to these boards to run coreboot on them - and any user may give back to the project one day.
Hopefully my post above explains why I think "dropping 50 boards is a bad idea", although I agree that it would be nice to get a resource allocator v4 working on them.
On Thu, Nov 25, 2021 at 12:46 AM ron minnich <rminnich@gmail.com> wrote:
The word 'drop' has ominous connotations, but it's not a deletion. A board is never really gone. It's git. I can still find the Alpha boards in there if I go back far enough. It's just that active development ends, as no one is working to keep them up to date.
Would it be ok with you to drop the board, and bring it back when it is working again?
There is a cost to keeping boards too long when there is no one maintaining them. They may still build, but they can stop working. That's happened and in my view it's best not to let it happen. People should be able to count on a board working if they build an image.
Thanks
ron
On Wed, Nov 24, 2021 at 12:16 PM Mike Banon <mikebdp2@gmail.com> wrote:
With all due respect, dropping support for the majority of AMD boards - with a quite significant community around them! - doesn't seem like a wise decision, if we still care about the coreboot marketshare on the worldwide-available consumer PCs. Small improvement in the common source, but a huge loss of boards? (almost 50!). For the sake of the bright future of the coreboot project, this must be prevented at all costs...
Some time ago I did https://review.coreboot.org/c/coreboot/+/41431 change where tried to get a resource allocator V4 working for these AGESA boards, and despite a tiny size (less than 20 lines) - it almost worked, judging by that fam15h A88XM-E booted fine (although there might have been some other problems undercover). I wonder if it could help and will be happy to test the new changes related to this.
On Wed, Nov 24, 2021 at 8:52 PM Arthur Heymans <arthur@aheymans.xyz>
wrote:
We could announce this deprecation in the 4.16 release notes, then
deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
That timeline of 8.5 months does sound fair. I just found this
updated release schedule in the meeting minutes.
If we are going to release every 3 months then I guess that's a good way to go.
I started a CL: https://review.coreboot.org/c/coreboot/+/59618 . I'll update it to reflect that schedule if it can be agreed upon.
On Wed, Nov 24, 2021 at 6:07 PM Martin Roth <gaumless@tutanota.com> wrote:
Hey Arthur,
Nov 24, 2021, 05:50 by arthur@aheymans.xyz:
Hi I would like to suggest to deprecate some legacy codepaths inside
the coreboot tree and therefore make some newer ones mandatory.
... snip ...> About the timeline of deprecations. Is deprecating non conforming platforms from the master branch after the 4.16 release in 6 months a reasonable proposal?
I have no strong opinion about the platform deprecations, although I suspect that PC Engines might be unhappy if it's platforms were removed from the ToT codebase.
My preference would be to announce deprecations in the release notes. We just missed the 4.15 release, but we're switching to a 3 month release cadence, so the next release will be in early February, 2.5 months from now.
We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
Would this schedule work?
Martin
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
It's definitely preferable to have platforms working in-tree rather than out of tree. This is a *significant* portion of coreboot's supported platforms and sends a strong signal to anyone using or considering them that they can just forget about the coreboot project because the rug may be pulled out from under them at any time. These users didn't contribute fixes to their boards (or even just feedback
that things needs to be done and testing when others provide patches) - are they even contributors? It's easy to argue in favor of "lots of users" (or contributors if you want), but if they're all but invisible, do they even exist?
People constantly complain about a lack of developer manpower, yet also don't care about how many users coreboot has. Do you not see that the only source of the former is from the latter? Loco is right about coreboot being more developer focused than user focused. While there is now (finally!) some sane documentation for simple things like creating a patch on gerrit, these few guides are very hard to find especially from the coreboot.org frontpage. I'm still not aware of anything even approaching a comprehensive porting guide. There is effectively no path for users to follow to fix even the simplest bug. (eg. I'd love to port from the AM1I-A to the AM1M-A, owning spares of both, but the lack of guidance makes the process a black hole of inestimable time) This is in STARK contrast to a project like PostmarketOS which puts a lot of thought into bringing users into development work. They have font-page guides that go into great detail on creating a new port. They even have detailed guides on how to port a phone to the mainline kernel, for absolute beginners. They have a simple all-in-one script that build the environment, can create the files for a new port, and can automatically package these changes for review. There are a lot of lessons to be learned from pmOS who ran into exactly this problem and fixed it. On Thu, Nov 25, 2021 at 12:17 PM Arthur Heymans <arthur@aheymans.xyz> wrote:
1. These boards will be gone for the people who check the "mainboards supported by coreboot" and see only the "new Intel stuff". This hinders the coreboot community growth around the "gone boards", and also of the coreboot community in general: the fewer boards are supported by coreboot, the more difficult it is for a potential user/contributor to find the supported board and join us.
Coreboot supports a lot more platforms than "new Intel stuff", which is quite an achievement. To make it possible for very different hardware in one branch, thoughtful design is needed. Supporting different codepaths to do the same thing blows up the complexity of maintenance and makes it harder to support both old and new boards as you lose track of how code changes can affect other systems. Keeping things simple is not optional in a project like coreboot. So it's not about adding a minor feature like you said in your previous email. It's really about keeping things manageable long term for everyone. That however requires some work from time to time on some platforms and sometimes dropping boards if no one steps up to do that work.
2. It's not just the loss of boards - it's also the loss of coreboot users/contributors who only have these boards and don't want to switch to anything else: i.e. because the newer coreboot-supported boards have Intel ME / AMD PSP that are viewed negatively by many people out of security considerations, - and security is one of the top reasons why the people switch to coreboot in the first place.
Sorry, not buying that argument at all for AMD AGESA supported platforms. I don't see a lot of development on gerrit for these platforms especially in comparison with Intel ones of similar age.
Regards Arthur
On Thu, Nov 25, 2021 at 5:04 PM Mike Banon <mikebdp2@gmail.com> wrote:
The word 'drop' has ominous connotations, but it's not a deletion. A board is never really gone.
"Dropping" 50 boards may be ominous in relation to the future of the coreboot project:
1. These boards will be gone for the people who check the "mainboards supported by coreboot" and see only the "new Intel stuff". This hinders the coreboot community growth around the "gone boards", and also of the coreboot community in general: the fewer boards are supported by coreboot, the more difficult it is for a potential user/contributor to find the supported board and join us.
2. It's not just the loss of boards - it's also the loss of coreboot users/contributors who only have these boards and don't want to switch to anything else: i.e. because the newer coreboot-supported boards have Intel ME / AMD PSP that are viewed negatively by many people out of security considerations, - and security is one of the top reasons why the people switch to coreboot in the first place.
3. Unless someone will be manually copying all the time, these boards won't get the updates of the common coreboot parts, even if such updates aren't related to the deletion reason. A reason which won't be understood by the opensource-loving community around the world - on Phoronix etc. - as good enough for "50 boards drop" - so doing this may harm the reputation of a coreboot project.
Of course, the people may finally fork a coreboot to i.e. "coreboot_extended" or "coreboot_notcorporate" (need a good name) and continue contributing there. Such a fork may even become more popular than the original coreboot of the future, because it will support significantly more boards. But, if this happens, it will fragment the coreboot community and split / spread thin our joint efforts for not a good enough reason.
It's just that active development ends, as no one is working to keep them up to date. There is a cost to keeping boards too long when there is no one maintaining them.
Even right now there's an active development & maintainership (as evidenced by all these changes at review.coreboot.org), - just not for this v4 resource allocator.
Would it be ok with you to drop the board, and bring it back when it is working again?
I'm not sure I understand: at least my boards from this list are working perfectly at the moment.
They may still build, but they can stop working. People should be able to count on a board working if they build an image.
I am often build-testing my boards (didn't notice a https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but only because I've been re-using the previously built toolchains to save time). Also, I am actively tech-supporting all the people who would like to build coreboot for AMD boards from this list, even right now I am in an active message exchange with >10 people who are switching to these boards to run coreboot on them - and any user may give back to the project one day.
Hopefully my post above explains why I think "dropping 50 boards is a bad idea", although I agree that it would be nice to get a resource allocator v4 working on them.
On Thu, Nov 25, 2021 at 12:46 AM ron minnich <rminnich@gmail.com> wrote:
The word 'drop' has ominous connotations, but it's not a deletion. A board is never really gone. It's git. I can still find the Alpha boards in there if I go back far enough. It's just that active development ends, as no one is working to keep them up to date.
Would it be ok with you to drop the board, and bring it back when it is working again?
There is a cost to keeping boards too long when there is no one maintaining them. They may still build, but they can stop working. That's happened and in my view it's best not to let it happen. People should be able to count on a board working if they build an image.
Thanks
ron
On Wed, Nov 24, 2021 at 12:16 PM Mike Banon <mikebdp2@gmail.com> wrote:
With all due respect, dropping support for the majority of AMD boards - with a quite significant community around them! - doesn't seem like a wise decision, if we still care about the coreboot marketshare on the worldwide-available consumer PCs. Small improvement in the common source, but a huge loss of boards? (almost 50!). For the sake of the bright future of the coreboot project, this must be prevented at all costs...
Some time ago I did https://review.coreboot.org/c/coreboot/+/41431 change where tried to get a resource allocator V4 working for these AGESA boards, and despite a tiny size (less than 20 lines) - it almost worked, judging by that fam15h A88XM-E booted fine (although there might have been some other problems undercover). I wonder if it could help and will be happy to test the new changes related to this.
On Wed, Nov 24, 2021 at 8:52 PM Arthur Heymans <arthur@aheymans.xyz>
wrote:
We could announce this deprecation in the 4.16 release notes,
then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
That timeline of 8.5 months does sound fair. I just found this
updated release schedule in the meeting minutes.
If we are going to release every 3 months then I guess that's a good way to go.
I started a CL: https://review.coreboot.org/c/coreboot/+/59618 . I'll update it to reflect that schedule if it can be agreed upon.
On Wed, Nov 24, 2021 at 6:07 PM Martin Roth <gaumless@tutanota.com> wrote:
Hey Arthur,
Nov 24, 2021, 05:50 by arthur@aheymans.xyz:
> Hi > I would like to suggest to deprecate some legacy codepaths
inside the coreboot tree and therefore make some newer ones mandatory.
> ... snip ...> About the timeline of deprecations. Is deprecating non conforming platforms from the master branch after the 4.16 release in 6 months a reasonable proposal? > I have no strong opinion about the platform deprecations, although I suspect that PC Engines might be unhappy if it's platforms were removed from the ToT codebase.
My preference would be to announce deprecations in the release notes. We just missed the 4.15 release, but we're switching to a 3 month release cadence, so the next release will be in early February, 2.5 months from now.
We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
Would this schedule work?
Martin
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Mike, I typically don't indulge in mailing list drama, but I'm sick and tired of seeing people waste their time and energy along with others'. This is not the first time I've seen something like this: something similar happened about two years ago when other AMD boards (KGPE-D16 and KCMA-D8, among others) were slated for removal. It was a difficult decision, but had to be done. I really don't want history to repeat itself again, but I fear it's going to happen unless there's a change of attitude right now. On Thu, Nov 25, 2021 at 4:05 PM Mike Banon <mikebdp2@gmail.com> wrote:
The word 'drop' has ominous connotations, but it's not a deletion. A board is never really gone.
"Dropping" 50 boards may be ominous in relation to the future of the coreboot project:
Note that these boards will only be dropped if no one steps up to adapt their code accordingly. Moreover, the first deprecation notice for RESOURCE_ALLOCATOR_V3 was issued as part of the coreboot 4.13 release notes, i.e. last year. The removal was postponed indefinitely because https://review.coreboot.org/q/topic:amd_resource_allocator_v4 implements the required changes. However, not all patches have landed yet, and efforts seem to have stalled: as of writing, all but one of the unmerged changes were last updated in May 2021, and the outlier was last updated in 2021-06-23. Hopefully, this notice will reactivate efforts to get these patches submitted without reactivating the local mailing list volcanoes. IMHO, lamenting about deprecation notices on the mailing list is counterproductive: it invests no resources into addressing the root problem (code needs to be maintained, but isn't), but instead tries to somehow avoid having to address the root problem by inciting emotional responses from others, such as anger. In my experience, this is a recipe for a conflict, a bitterly unpleasant waste of many people's time and energy for naught, leading to an equally disgraceful aftermath; a war in which most of the casualties are motives to work on the project. Wouldn't it be much more useful to, say, work on adapting the code, add new features or improve existing functionality, write some documentation, or even check the grammar of the code comments in the tree?
1. These boards will be gone for the people who check the "mainboards supported by coreboot" and see only the "new Intel stuff". This hinders the coreboot community growth around the "gone boards", and also of the coreboot community in general: the fewer boards are supported by coreboot, the more difficult it is for a potential user/contributor to find the supported board and join us.
In my experience, most people who've contributed didn't have a supported board. I myself got involved with the coreboot community because none of the boards I had was supported; about three and a half years later, I now am one of the most active contributors. I only tolerated the bugs and limitations of coreboot (let's be honest; we're not perfect and we don't provide the same features as vendor firmware) because I was experiencing first-hand how hard firmware development is. I'm pretty sure I wouldn't be writing this email had one of my boards already been supported. Granted, it's nearly impossible for a newcomer to port a board when its chipset is not supported. The first board I ported is the Asus P8H61-M PRO, an Intel Sandy/Ivy Bridge desktop board with a serial port and a socketed DIP8 flash chip. Back then, Sandy/Ivy Bridge was one of the best-supported platforms (and still is, as of writing). Several people on IRC (to which I'm forever thankful) helped me port this board. I only know of one person on IRC that could help porting an AMD board using AGESA, and there aren't many people who have AGESA-supported boards.
2. It's not just the loss of boards - it's also the loss of coreboot users/contributors who only have these boards and don't want to switch to anything else: i.e. because the newer coreboot-supported boards have Intel ME / AMD PSP that are viewed negatively by many people out of security considerations, - and security is one of the top reasons why the people switch to coreboot in the first place.
First and foremost, there's support for older Intel boards that don't require ME firmware or simply don't have a ME at all, and people still use them. Besides AMD AGESA boards, the other boards that need to be updated are AOpen DXPL Plus-U (a dual-socket server board that uses Netburst Xeons, no other board in the tree uses the same chipset code) and various Asus P2B boards (which support Pentium 2/3 CPUs, these boards are older than me). Even though I only know two people who still have some of these boards (and they don't have the same boards), they're still supported because the code has been maintained so far. If there are contributors who only have these boards, where are they? Why aren't they trying to adapt the code? If they don't know how, why haven't they asked for help on how to proceed? I understand that most users wouldn't know how to implement the required changes, but they can still test things! If they don't want to test things, they might as well keep using the coreboot image they're currently running.
3. Unless someone will be manually copying all the time, these boards won't get the updates of the common coreboot parts, even if such updates aren't related to the deletion reason. A reason which won't be understood by the opensource-loving community around the world - on Phoronix etc. - as good enough for "50 boards drop" - so doing this may harm the reputation of a coreboot project.
I'm sure the effort required to adapt the affected platforms is less than the effort required to backport changes from coreboot master. As to whether dropping boards may harm the reputation of the coreboot project, it's unclear. Some people will hate it, others will be sad about it, and others will understand that dragging support for platforms no one is maintaining is unnecessary burden. As a developer, I'd rather support less platforms and make them work well than try to support everything at the expense of quality.
Of course, the people may finally fork a coreboot to i.e.
Who does "the people" refer to? The maintainers of these boards? The users? I have no clue, could you please elaborate?
"coreboot_extended" or "coreboot_notcorporate" (need a good name) and
This is an insult to the coreboot community. A significant amount of contributions don't come from corporations. One of the most important contributions to coreboot has been Sandy/Ivy Bridge native raminit, which wasn't done by corporations. In fact, native raminit is reimplementation of the MRC.bin introduced by corporations. Let's not forget about the origins of AGESA. As far as I'm aware, it came from AMD and hasn't seen much non-corporate development, let alone any efforts to reimplement its functionality. How exactly is AGESA not corporate?
continue contributing there. Such a fork may even become more popular than the original coreboot of the future, because it will support significantly more boards.
I'm very interested in knowing what your plans are to make such a promising fork thrive. How would a fork require less work than backporting the changes from coreboot master? Unlike continuing development in a branch, a fork would not be able to reuse the existing coreboot infrastructure (e.g. Gerrit, Jenkins...). Would the maintainers of such a fork also maintain the boards supported by upstream coreboot?
But, if this happens, it will fragment the coreboot community and split / spread thin our joint efforts for not a good enough reason.
How exactly does threatening to fork avoid fragmenting the coreboot community? Wouldn't it be much better to focus on the root problem, that platform code needs to be adapted and tested? Or is there a good enough reason that I have completely missed?
It's just that active development ends, as no one is working to keep them up to date. There is a cost to keeping boards too long when there is no one maintaining them.
Even right now there's an active development & maintainership (as evidenced by all these changes at review.coreboot.org), - just not for this v4 resource allocator.
Could you please provide concrete pointers to this "active development & maintainership" you're referring to?
Would it be ok with you to drop the board, and bring it back when it is working again?
I'm not sure I understand: at least my boards from this list are working perfectly at the moment.
So you have the hardware. Would it be OK with you to test patches that implement the required changes? Or even better, would you like to try implementing such changes? Why not both?
They may still build, but they can stop working. People should be able to count on a board working if they build an image.
I am often build-testing my boards (didn't notice a https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but only because I've been re-using the previously built toolchains to save time). Also, I am actively tech-supporting all the people who would like to build coreboot for AMD boards from this list, even right now I am in an active message exchange with >10 people who are switching to these boards to run coreboot on them - and any user may give back to the project one day.
Helping out 10 people at the same time sounds stressful. Would writing some documentation for https://doc.coreboot.org/ on how to get coreboot running on these boards reduce the amount of work you need to do?
Hopefully my post above explains why I think "dropping 50 boards is a bad idea", although I agree that it would be nice to get a resource allocator v4 working on them.
So, if you agree that making them work with resource allocator v4, why not work on getting https://review.coreboot.org/q/topic:amd_resource_allocator_v4 submitted? It doesn't look like a lot of effort. I'll be happy to help review these changes: my reviews are remarkably rigorous, but I'm not a draconian warden of the submit button.
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
TL;DR: The deprecation notice is a call for action. Please stop complaining about it, let's work on a solution instead. Especially when https://review.coreboot.org/q/topic:amd_resource_allocator_v4 already exists, which implements some of the required changes. Best regards, Angel
On Thu, Nov 25, 2021 at 9:50 PM Angel Pons <th3fanbus@gmail.com> wrote:
TL;DR: The deprecation notice is a call for action. Please stop complaining about it, let's work on a solution instead. Especially when https://review.coreboot.org/q/topic:amd_resource_allocator_v4 already exists, which implements some of the required changes.
Thanks for your thoughts, Angel. Seems like my first contribution to coreboot just reached the age of 10 years. commit 521d8c25734dcfd38fa2e17a416e587fccb96080 Author: Kyösti Mälkki <kyosti.malkki@gmail.com> Date: Mon Oct 17 17:10:03 2011 +0300 Activate older Xeon P4 microcodes This was for one of the boards on the deprecation list, aopen/dxplplusu. No SPI flash, ASEG SMM (TSEG available), no compulsory SMI_HANDLER, no PCI MMCONFIG (now ECAM). CPU without x86_64, only 34bit PAE, somewhat complex CAR bringup, 2 power-hungry socketed P4 Xeon CPUs. No PCIe, some PCI-X slots, DDR1 with ECC, Parallel ATA no SATA. I think I have touched the chipset support maybe 3 times in the last 5 years --- still boots with iPXE to iSCSI root. It is likely to survive this deprecation of LEGACY_SMP_INIT too. I think OEM BIOS had a date like from 2005. For a contributor I find competent and interested enough, I might offer some of the following AGESA boards as a donation: * lippert/frontrunner-af (fam14 liano?) * gizmosphere/gizmo (fam14 liano?) * pcengines/apu1 (fam14 liano?) * amd/olivehill (fam16 kabini) * asrock/imb-a180 (fam16 kabini) * lenovo/g505s (fam15 trinity/richland) * ibase/i595f (fam15 trinity/richland, reaches payload with serial console, not really ported) Contact me privately to discuss terms and possible shipment. I may not be able to provide much documentation, many I have are NDA'd. AFAICS master and release 4.15 are in a booting condition for all the above with allocator V3. Like with C_ENV_BOOTBLOCK (previous valid and sensible deprecation reason) I can participate with the review progress. If I remember correctly, it was you Mike B. and Michal Z. who did most of the legwork then. I feel I have personally contributed enough with little returned value to AGESA, but a lot of soc/amd/common should be reusable for TSEG, PARALLEL_MP and also cleaner SPI Flash write support and MRC_WR_CACHE (fam16kb). There may still be a lot of assumptions of HyperTransport and multiple CPU sockets under nb/ that should be cleaned too. From experience, I can tell having parallel implementations for a single task is both a development headache with lots of preprocessor guards involved, and slows down the review process a lot. From what I remember allocator V3 does not play well with large graphics framebuffers or 64bit resources in general and I feel it's time to let it go. Also, feel free to study the history of deprecations and imagine what the tree would look like if we still allowed things like a static allocation for CBMEM done late in ramstage, or optional choice of CAR_MIGRATION or ROMCC. As I see it, forced deprecation is the only means to wake up the small group of people who are competent enough to take on a task like PARALLEL_MP migration, but are mostly just waiting for someone else to volunteer first. Maybe with some luck they provide feedback by testing builds when requested, often feedback arrives 6 months later revealing something broken. My ballpark estimation is a total of less than 100hours of contributors' time to migrate AGESA platform codes to avoid deprecation. Shared between five people who know what they are doing, it is very much doable within a month. Kind regards, Kyösti Mälkki
I'm happy to contribute financially. It just comes with the caveat that I need to know with some surety that I can finally have a working board at the end of it. On a side note is there any kind of crowd sourcing platform / escrow service for GPL projects? I know it's been talked about, and there have been attempts made. But as far as I can tell, nothing has ever prospered.
My ballpark estimation is a total of less than 100hours of contributors' time to migrate AGESA platform codes to avoid deprecation. Shared between five people who know what they are doing, it is very much doable within a month.
Kind regards, Kyösti Mälkki _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
1. These boards will be gone for the people who check the "mainboards
supported by coreboot" and see only the "new Intel stuff". This hinders the coreboot community growth around the "gone boards", and also of the coreboot community in general: the fewer boards are supported by coreboot, the more difficult it is for a potential user/contributor to find the supported board and join us.
For the record, we have removed Intel boards from the master branch in the past - See 4.11_branch. This was for boards that used FSP 1.0, including popular Baytrail Atom and Broadwell-DE platforms which are still widely used today. This ensures that those platforms continue existence on an easy-to-find stable branch where one can reasonably expect to check out the code and have it work. Checking out the master branch only to find out that it doesn't work and then bisecting years worth of commits is a poor user experience. Perhaps we should follow the 4.11_branch example and do something similar with old AGESA boards? Boards which are forward-ported and tested can stay (or be re-introduced) in the master branch, of course. Many of the AGESA platforms in the list Arthur provided are ~10 years old. Some are clearly obsolete, like the Gizmosphere boards that have not been in production for years and whose manufacturer is defunct. Others like the PCEngines APUs should be more readily available to test and have developers able to spend some time forward-porting the necessary bits. Lastly, I'll mention that there is an active crowdfunding effort to re-upstream KGPE-D16 support: https://github.com/osresearch/heads/issues/719. There's clearly a lot of enthusiasm with that board, and 3mdeb is already porting allocate v4 to it. Perhaps enthusiasts for other boards can piggyback on this effort and leverage some of their work to bring other boards up to date.
having read this discussion, and with all respect for all the opinions so clearly expressed, I still support Arthur's original proposal. On Sun, Nov 28, 2021 at 2:20 PM David Hendricks <david.hendricks@gmail.com> wrote:
1. These boards will be gone for the people who check the "mainboards supported by coreboot" and see only the "new Intel stuff". This hinders the coreboot community growth around the "gone boards", and also of the coreboot community in general: the fewer boards are supported by coreboot, the more difficult it is for a potential user/contributor to find the supported board and join us.
For the record, we have removed Intel boards from the master branch in the past - See 4.11_branch. This was for boards that used FSP 1.0, including popular Baytrail Atom and Broadwell-DE platforms which are still widely used today. This ensures that those platforms continue existence on an easy-to-find stable branch where one can reasonably expect to check out the code and have it work. Checking out the master branch only to find out that it doesn't work and then bisecting years worth of commits is a poor user experience.
Perhaps we should follow the 4.11_branch example and do something similar with old AGESA boards? Boards which are forward-ported and tested can stay (or be re-introduced) in the master branch, of course.
Many of the AGESA platforms in the list Arthur provided are ~10 years old. Some are clearly obsolete, like the Gizmosphere boards that have not been in production for years and whose manufacturer is defunct. Others like the PCEngines APUs should be more readily available to test and have developers able to spend some time forward-porting the necessary bits.
Lastly, I'll mention that there is an active crowdfunding effort to re-upstream KGPE-D16 support: https://github.com/osresearch/heads/issues/719. There's clearly a lot of enthusiasm with that board, and 3mdeb is already porting allocate v4 to it. Perhaps enthusiasts for other boards can piggyback on this effort and leverage some of their work to bring other boards up to date.
On a side note is there any kind of crowd sourcing platform / escrow service for GPL projects? I know it's been talked about, and there have been attempts made. But as far as I can tell, nothing has ever prospered.
If someone wanted to work with one of the approved coreboot contractors
or individual contributor to set up a fundraiser of some sort to raise money to do things like this, that'd be great. We've had a requests for things like this in the past, but it's not something that the coreboot project itself can really do. We don't want to pit one group of coreboot developers against another, and the coreboot project also doesn't deliver binaries or sign contracts for work, so coreboot can't make guarantees about deliverables.I'd be happy to help get a fundraiser set up if anyone is interested in doing the work, but it's going to have to go through an actual fundraising site, and of course we'd want to have a full written plan before starting anything.
I've seen bountysource employed for various things in the past, from compatibility enhancements for POWER9 to GCC backend implementations for AVR. I think it's reasonably fair, with the bounty available to whoever is willing to put in the work to close the issue. The only thing missing that I can see is the need for an "issue" (a la github issues) that can be "closed" to trigger the end of the bounty. I don't know if gerrit supports such a functionality. On Sun, Nov 28, 2021 at 9:46 PM ron minnich <rminnich@gmail.com> wrote:
having read this discussion, and with all respect for all the opinions so clearly expressed, I still support Arthur's original proposal.
On Sun, Nov 28, 2021 at 2:20 PM David Hendricks <david.hendricks@gmail.com> wrote:
1. These boards will be gone for the people who check the "mainboards supported by coreboot" and see only the "new Intel stuff". This hinders the coreboot community growth around the "gone boards", and also of the coreboot community in general: the fewer boards are supported by coreboot, the more difficult it is for a potential user/contributor to find the supported board and join us.
For the record, we have removed Intel boards from the master branch in
the past - See 4.11_branch. This was for boards that used FSP 1.0, including popular Baytrail Atom and Broadwell-DE platforms which are still widely used today. This ensures that those platforms continue existence on an easy-to-find stable branch where one can reasonably expect to check out the code and have it work. Checking out the master branch only to find out that it doesn't work and then bisecting years worth of commits is a poor user experience.
Perhaps we should follow the 4.11_branch example and do something
similar with old AGESA boards? Boards which are forward-ported and tested can stay (or be re-introduced) in the master branch, of course.
Many of the AGESA platforms in the list Arthur provided are ~10 years
old. Some are clearly obsolete, like the Gizmosphere boards that have not been in production for years and whose manufacturer is defunct. Others like the PCEngines APUs should be more readily available to test and have developers able to spend some time forward-porting the necessary bits.
Lastly, I'll mention that there is an active crowdfunding effort to
re-upstream KGPE-D16 support: https://github.com/osresearch/heads/issues/719. There's clearly a lot of enthusiasm with that board, and 3mdeb is already porting allocate v4 to it. Perhaps enthusiasts for other boards can piggyback on this effort and leverage some of their work to bring other boards up to date. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
24. November 2021 21:16, "Mike Banon" <mikebdp2@gmail.com> schrieb:
With all due respect, dropping support for the majority of AMD boards
Dropping support for hardware has never been the primary purpose of deprecation plans, but since deprecations have been interpreted like that too often, I propose using clearer language going forward. I'd appreciate comments on https://review.coreboot.org/c/coreboot/+/59677 to ensure that it brings the point across. Regards, Patrick
TL;DR: If someone wants to deprecate older code then *they* have to first balance any compatibility debt introduced by the newer code. Anything else incentivises a race to the bottom; to move fast and break things. coreboot IMO neither wants nor needs that. Patrick Georgi via coreboot wrote:
With all due respect, dropping support for the majority of AMD boards
Dropping support for hardware has never been the primary purpose of deprecation plans,
I think the difference is unimportantly subtle; deprecation is formal intent to (eventually) drop. Deprecating code that not only provably works on hardware but is in fact *our only* code that currently works on the hardware IMO falls between lazy and malicious, in any case far from good practice when considering the future. Our classic tension between private interests and the public good will not diminish over time unless everyone invests towards that goal. The Linux kernel is a perfect example of what happens otherwise, it's certainly nothing to strive for. I consider Arthur's argument about maintenance burden to be based on the false premise that newer code is per se more valuable than older code. If only considering hardware running the newer code with tunnel vision I do understand such an attitude, but to me a hard requirement for such a premise is that the newer code is a drop-in replacement - only then is it prudent to speak of deprecating the older code. If it's not compatible then the new code obviously solves a different problem. It's of course too late to enforce drop-in compatibility once new code has been accepted into the tree, but the desire for deprecation such as this is a good opportunity to pay back what I consider compatibility debt in the new code. Accepting an incompatible new implementation fails to create the incentives required for medium to long-term codebase stability. It would be wise to start repairing that culture deficit right now. I find it completely unacceptable for someone working on something new to push a workload of forward-porting onto people who have no relation whatsoever to that new effort, but I'm sure it's a fun power trip. :) Please be more mindful than that. I've of course also made mistakes, but I try to always improve. If companies are unable to invest in creating open source firmware for the public good then please think about whether you really want to be known for introducing compatibility debt. If companies are able but merely unwilling then please be honest about that and do not bother others with your code, you should maintain it locally then. No progress can be infinitely better than "wrong" progress, and therein lies the challenge for private interests in projects for the public good. A strange game! Kind regards //Peter
Am 28.11.2021 um 02:44 schrieb Peter Stuge:
Patrick Georgi via coreboot wrote:
With all due respect, dropping support for the majority of AMD boards
Dropping support for hardware has never been the primary purpose of deprecation plans,
I think the difference is unimportantly subtle; deprecation is formal intent to (eventually) drop. I'll try to make it clearer: Dropping support FOR HARDWARE has never been the primary purpose of deprecation plans
The primary goal, as seen in the title, is to remove LEGACY_SMP_INIT and RESOURCE_ALLOCATOR_V3. One purpose of announcements like the one by Arthur is to start a discussion how to get there while ideally NOT dropping the devices that would be affected (as listed in the original email). I'll leave the rest of the email uncommented because it's only derailing matters even more. Regards, Patrick
Hi Peter, On 28.11.21 02:44, Peter Stuge wrote:
TL;DR: If someone wants to deprecate older code then *they* have to first balance any compatibility debt introduced by the newer code.
sounds fair. However I have to ask, do you see things are unbalanced? And in what direction? Taking the allocator case for instance, there is zero compatibility debt introduced by the new code. All the debt is within the code of the deprecated platforms, which is neither compatible to the old nor the new allocator code. It's just buggy. Always has been. Changing core coreboot code just makes this more visible, and to me it seems fairer to deprecate broken code than to pretend that it's working. Overall, all the cases of dropped platforms that I can recall are of this kind: Somebody pushed their code upstream and then they or somebody relying on the code tried to get their bugs fixed for free by coreboot maintainers. IMHO, this is heavily unbalanced and depre- cation are a means to fix that.
Anything else incentivises a race to the bottom; to move fast and break things. coreboot IMO neither wants nor needs that.
Sounds right. But I guess you assumed things are unbalanced in a different direction than they are :)
Patrick Georgi via coreboot wrote:
With all due respect, dropping support for the majority of AMD boards
Dropping support for hardware has never been the primary purpose of deprecation plans,
I think the difference is unimportantly subtle; deprecation is formal intent to (eventually) drop.
No, not unconditionally and definitely not eventually. Their is always hope that somebody tries to fix the platforms that rely on deprecated code.
Deprecating code that not only provably works on hardware but is in fact *our only* code that currently works on the hardware IMO falls between lazy and malicious, in any case far from good practice when considering the future.
tl;dr that code works by coincidence is not enough to ask other people to maintain it. You may not have read the code of the platforms in question. I did and IMHO, if anything is malicious then it's having such broken, impossible to maintain code in our tree. Looking at the code, I have to assume it was added with minimum effort to write sound code and maximum debt. People have worked to fix it and clean it up for years and it's still in a (IMHO) horrible state. Pushing such code into the tree "falls between lazy and malicious". Asking to keep such code without the intention to fix it, too.
Our classic tension between private interests and the public good will not diminish over time unless everyone invests towards that goal. The Linux kernel is a perfect example of what happens otherwise, it's certainly nothing to strive for.
What's the public good in this case? Isn't it for the public good when people like Arthur continue to support projects like coreboot? You seem a little too biased towards existing code, but what about new code? Is there no public interest in new code?
I consider Arthur's argument about maintenance burden to be based on the false premise that newer code is per se more valuable than older code.
Ok, your are free to consider it like this. But I can tell you it's wrong. IIRC, all the deprecation up to now were in favor of code that turned out to work best for all sound coreboot ports. Of course, new code doesn't always work well for ports that only worked by coincidence with the old code, and there's the burden. Who's responsible to fix code that was added in a poor state? The original authors? the people who rely on it? or the people who want to continue the project?
If only considering hardware running the newer code with tunnel vision I do understand such an attitude, but to me a hard requirement for such a premise is that the newer code is a drop-in replacement - only then is it prudent to speak of deprecating the older code. If it's not compatible then the new code obviously solves a different problem.
It's of course too late to enforce drop-in compatibility once new code has been accepted into the tree, but the desire for deprecation such as this is a good opportunity to pay back what I consider compatibility debt in the new code.
Accepting an incompatible new implementation fails to create the incentives required for medium to long-term codebase stability. It would be wise to start repairing that culture deficit right now.
Again, the incompatibility burden is usually not introduced by the new code. What you say seems generally true, but you are blaming / talking to the wrong people. It's not what is going on in this project.
I find it completely unacceptable for someone working on something new to push a workload of forward-porting onto people who have no relation whatsoever to that new effort, but I'm sure it's a fun power trip. :)
I find it completely unacceptable for someone adding broken code to push a workload of fixing onto people who have no relation whatsoever to the platforms in question. Not sure how you can say such things with a smile.
Please be more mindful than that. I've of course also made mistakes, but I try to always improve.
Well, please try in this instance too. It feels very awkward to write this. It seems you are blaming people for things they didn't do and support people who pack all the work on the former's backs.
If companies are unable to invest in creating open source firmware for the public good then please think about whether you really want to be known for introducing compatibility debt.
Companies? So far it has always been a community effort to deprecate and companies objected. Not always, but often, code is maintained in our tree in the interest of companies. And such deprecation is our only means to keep breathing under the burden.
If companies are able but merely unwilling then please be honest about that and do not bother others with your code, you should maintain it locally then.
What are you talking about? It seems you got everything backwards :( Nico
participants (16)
-
Angel Pons -
AreYouLoco? -
Arthur Heymans -
awokd -
David Hendricks -
Keith Emery -
Kyösti Mälkki -
Martin Roth -
Matt B -
Mike Banon -
Nico Huber -
Patrick Georgi -
patrick＠coreboot.org
-
Paul Menzel -
Peter Stuge -
ron minnich