On 05.11.21 18:15, Martin Roth via coreboot wrote:
Nov 4, 2021, 05:24 by pmenzel@molgen.mpg.de:
On 20.10.21 14:24, Nico Huber wrote:
My proposal: How about we set up some guidelines how to proceed when adding support for a new platform that requires any blobs? My vague idea is as follows: Before the very first commit for such a new platform can be merged, a set of predefined, blob related questions (to be discussed) should be answered. This should also apply if a new platform just brings the same kind of blobs with it as its predecessor (e.g. next gen FSP). Situations may change and blobs do too. Speaking of FSP, it's actually a set of many blobs. I think questions should be answered for each part of it individually. ...>> What do you think?
Thank you for bringing this up, and I totally agree. Reaching out to the coreboot community and including it in the planing phase is currently lacking quite a lot. The coreboot mailing list is the perfect forum for that, but unfortunately not used a lot.>> Kind regards, Paul
The current reality is that binary blobs are needed for almost every platform in coreboot. I believe the coreboot leadership is united behind the unfortunate reality that allowing these blobs is a requirement for the platform.
Not sure what you are trying to say. Do you mean we shouldn't talk about the way blobs are added because they are needed anyway? Blobs are needed anyway so we won't review code around them any more?
I don't think we're going to refuse a platform right now simply because it has blobs.
Nobody brought that up. What are you referring to?
I'm not sure what coreboot would look like right now if we'd started refusing blobs when the required blobs started appearing, but it definitely wouldn't have many modern platforms.
That's a very hypothetical, IMO wrong statement. "definitely" is a very strong word there. Also, what's a "required blob" anyway? Most of the blobs in coreboot are not required but politically desired. As an ex- perienced coreboot developer who has written fully open-source platform support in the past, I would expect this to have happened: We'd have less ARM platforms in the tree because those were added for Chromebooks with little interest from other folks. On the x86 end, we'd be behind about a year compared to the support we have today, as other companies who rely less on the silicon vendor's blessing might have done the job. The community would look much different. Instead of many developers struggling to bring blobs up, we'd have less but much better experienced developers who still understand the hardware.
Of course we'll never know which scenario would have been more likely. But it's been almost ten years, a lot could have happened. Imagine coreboot would have been FSP free, maybe even AMD would have been more open to a free software solution. FWIW, FSP encourages a lot of people to put more and more code into blobs. IMO we are stuck in a corner, and you want us to stay there as calm as possible.
We all agree that we don't like adding more proprietary binaries, but there are times when a binary needs to be closed for a time until the platform is released such as with the PSE. This should be acceptable, so long as the promise is actually followed through upon. If not, the company making that promise loses credibility. Unfortunately, that's not always a great motivator. Maybe the coreboot organization & SFC can enter into a contract that specified a rough timeframe that the firmware would be open sourced. Hopefully that would be enough of a guarantee.
You know that the PSE is an Intel thing and still talk about credibility? Do you have any idea what is going on around their blobs? There are even claims in our documentation today that can't be explained and look like very weak excuses for the simple fact: The blob interface was done like this because Intel wanted it and all promises were only made to get the patch in. That Intel lost its credibility on the matter is one reason why it is hard to get things like the PSE support added. I think we need a better process so the developers tasked with such things don't suffer. And they should never be in a position that needs them to make promises. Individuals can't make promises on behalf of a huge company, that would be gambling, IMO, and we would never get an official, written promise anyway. So please forget about promises.
Simply refusing to accept the binaries *only hurts us*, most companies will be probably happy using Slimboot or TianoCore. Making things difficult to work with coreboot only makes it easier to show why something shouldn't be open and why the chip vendors shouldn't work with coreboot. I cant tell you how many times I've heard that the reason coreboot wasn't used or wasn't upstreamed was that it takes too long to get changes into coreboot.
Again not sure why you bring that up? I started a thread to make things easier. Why do you want to make it harder?
Nico
Nov 6, 2021, 05:21 by nico.h@gmx.de:
On 05.11.21 18:15, Martin Roth via coreboot wrote:
Nov 4, 2021, 05:24 by pmenzel@molgen.mpg.de:
On 20.10.21 14:24, Nico Huber wrote:
My proposal: How about we set up some guidelines how to proceed when adding support for a new platform that requires any blobs? My vague idea is as follows: Before the very first commit for such a new platform can be merged, a set of predefined, blob related questions (to be discussed) should be answered. This should also apply if a new platform just brings the same kind of blobs with it as its predecessor (e.g. next gen FSP). Situations may change and blobs do too. Speaking of FSP, it's actually a set of many blobs. I think questions should be answered for each part of it individually. ...>> What do you think?
Thank you for bringing this up, and I totally agree. Reaching out to the coreboot community and including it in the planing phase is currently lacking quite a lot. The coreboot mailing list is the perfect forum for that, but unfortunately not used a lot.>> Kind regards, Paul
The current reality is that binary blobs are needed for almost every platform in coreboot. I believe the coreboot leadership is united behind the unfortunate reality that allowing these blobs is a requirement for the platform.
Not sure what you are trying to say. Do you mean we shouldn't talk about the way blobs are added because they are needed anyway? Blobs are needed anyway so we won't review code around them any more?
Not at all, you can talk all you want. But what's the outcome you're looking for? Do it the coreboot way, or.... or what? Or we won't accept code to load those blobs? You won't accept ANY of the code for the platform? Is there a different end point if they don't do what you want?
To me, your statement below *VERY* much sounds like refusing a platform. Maybe you could explain what it actually means. I read it as "A vendor can't commit a new platform until the coreboot project is happy with the blob situation for the platform". ``` Oct 20, 2021, 06:24 by nico.h@gmx.de: My vague idea is as follows: Before the very first commit for such a new platform can be merged, a set of predefined, blob related questions (to be discussed) should be answered. ```
I don't think we're going to refuse a platform right now simply because it has blobs.
Nobody brought that up. What are you referring to?
See your above statement. If you'd said "at the start of a new project, we'd like to get the vendor to let us know what the blob situation looks like", sure. But the way it was phrased of "Before the first commit can be merged" says to me that you don't want to allow the platform to even get started in coreboot until you (or someone) is satisfied by the blob situation for the new platform. It's not like that discussion is going to be quick either. Blobs are ALWAYS contentious, which I'm fine with. I'm just not fine with blocking the progress of people who are trying to do their best to get their work done simply because we don't like blobs.
I'm not sure what coreboot would look like right now if we'd started refusing blobs when the required blobs started appearing, but it definitely wouldn't have many modern platforms.
That's a very hypothetical, IMO wrong statement. "definitely" is a very strong word there. Also, what's a "required blob" anyway? Most of the blobs in coreboot are not required but politically desired. As an ex- perienced coreboot developer who has written fully open-source platform support in the past, I would expect this to have happened: We'd have less ARM platforms in the tree because those were added for Chromebooks with little interest from other folks. On the x86 end, we'd be behind about a year compared to the support we have today, as other companies who rely less on the silicon vendor's blessing might have done the job. The community would look much different. Instead of many developers struggling to bring blobs up, we'd have less but much better experienced developers who still understand the hardware.
Of course we'll never know which scenario would have been more likely. But it's been almost ten years, a lot could have happened. Imagine coreboot would have been FSP free, maybe even AMD would have been more open to a free software solution. FWIW, FSP encourages a lot of people to put more and more code into blobs. IMO we are stuck in a corner, and you want us to stay there as calm as possible.
Just because it didn't happen doesn't mean it's simply hypothetical. ChromeOS pushing to not use the FSP didn't make intel reconsider it. AMD introduced the binary PI because they no longer had the resources to support open sourcing it. I'm sure what would have happened, and so is Patrick, when he said that coreboot would be gone if we had refused blobs.
And I think it's very presumptuous of you to assume that you know what it is that I want. "unfortunate reality that allowing these blobs is a requirement" and the part that you removed from the end of my email in your response where I talk about the work that's being done to try to get vendors to open their codebases, are *NOT* me saying that I want you to stay stuck in the corner with all the blobs, let alone being calm.
I'm actually working with vendors to get them to open their code, and have been doing so for a LONG time, thank you very much.
We all agree that we don't like adding more proprietary binaries, but there are times when a binary needs to be closed for a time until the platform is released such as with the PSE. This should be acceptable, so long as the promise is actually followed through upon. If not, the company making that promise loses credibility. Unfortunately, that's not always a great motivator. Maybe the coreboot organization & SFC can enter into a contract that specified a rough timeframe that the firmware would be open sourced. Hopefully that would be enough of a guarantee.
You know that the PSE is an Intel thing and still talk about credibility?
And I talked about ways to try to make them follow through on their promises.
Do you have any idea what is going on around their blobs? There are even claims in our documentation today that can't be explained and look like very weak excuses for the simple fact: The blob interface was done like this because Intel wanted it and all promises were only made to get the patch in. That Intel lost its credibility on the matter is one reason why it is hard to get things like the PSE support added. I think we need a better process so the developers tasked with such things don't suffer. And they should never be in a position that needs them to make promises. Individuals can't make promises on behalf of a huge company, that would be gambling, IMO, and we would never get an official, written promise anyway. So please forget about promises.
sorry, let me repeat this from my last email, maybe you missed it: Maybe the coreboot organization & SFC can enter into a contract that specified a rough timeframe that the firmware would be open sourced. Hopefully that would be enough of a guarantee.
Simply refusing to accept the binaries *only hurts us*, most companies will be probably happy using Slimboot or TianoCore. Making things difficult to work with coreboot only makes it easier to show why something shouldn't be open and why the chip vendors shouldn't work with coreboot. I cant tell you how many times I've heard that the reason coreboot wasn't used or wasn't upstreamed was that it takes too long to get changes into coreboot.
Again not sure why you bring that up? I started a thread to make things easier. Why do you want to make it harder?
CB:55367 was pushed on June 9th. It's 5 months later. Intel hasn't been able to get it merged yet. Sure, we're not outright saying they can't get it in, but in effect, that's what's happening. Do you disagree? Do you think that this is easy for the developers who are told by intel to get the patches merged? The coreboot project is difficult to work with. That's just the truth, whether you see it or not. I'm not making it any harder by having this discussion with you.
Best regards,Martin
On 07.11.21 00:11, Martin Roth wrote:
Nov 6, 2021, 05:21 by nico.h@gmx.de:
On 05.11.21 18:15, Martin Roth via coreboot wrote:
Nov 4, 2021, 05:24 by pmenzel@molgen.mpg.de:
On 20.10.21 14:24, Nico Huber wrote:
My proposal: How about we set up some guidelines how to proceed when adding support for a new platform that requires any blobs? My vague idea is as follows: Before the very first commit for such a new platform can be merged, a set of predefined, blob related questions (to be discussed) should be answered. This should also apply if a new platform just brings the same kind of blobs with it as its predecessor (e.g. next gen FSP). Situations may change and blobs do too. Speaking of FSP, it's actually a set of many blobs. I think questions should be answered for each part of it individually. ...>> What do you think?
Thank you for bringing this up, and I totally agree. Reaching out to the coreboot community and including it in the planing phase is currently lacking quite a lot. The coreboot mailing list is the perfect forum for that, but unfortunately not used a lot.>> Kind regards, Paul
The current reality is that binary blobs are needed for almost every platform in coreboot. I believe the coreboot leadership is united behind the unfortunate reality that allowing these blobs is a requirement for the platform.
Not sure what you are trying to say. Do you mean we shouldn't talk about the way blobs are added because they are needed anyway? Blobs are needed anyway so we won't review code around them any more?
Not at all, you can talk all you want. But what's the outcome you're looking for?
Awareness and knowledge within the community.
Do it the coreboot way, or.... or what?
Well that would be a bonus and I think talking about things early might at least give us a chance to achieve something. When new kinds of blobs are discussed last minute, their next iterations for the next chips are most likely already set in stone by other teams at the silicon vendor. If we discuss things late, we can never change a thing.
Or we won't accept code to load those blobs?
I think there are limits. For instance if a blob would be called from ramstage, never to return, and would even load the payload. Should we accept infrastructure for such a thing? I think no. But that's inde- pendent from my original proposal, because it shouldn't matter in such a case if we discuss it early or late ;)
You won't accept ANY of the code for the platform?
In an unlikely, hypothetical case as described above, yes. Would you?
Is there a different end point if they don't do what you want?
Sorry, when did I ever bring in what I want? Does talking about some- thing imply to you that always someone tries to enforce their will on somebody else?
Talking about things can bring people together. I hope even in a community that is divided such as ours. Adding new blob infrastructure in a hurry does not bring people together. All I wanted is to talk about better ways to do it.
To me, your statement below *VERY* much sounds like refusing a platform. Maybe you could explain what it actually means. I read it as "A vendor can't commit a new platform until the coreboot project is happy with the blob situation for the platform".
Oct 20, 2021, 06:24 by nico.h@gmx.de: My vague idea is as follows: Before the very first commit for such a new platform can be merged, a set of predefined, blob related questions (to be discussed) should be answered.
It's not a statement, it was a proposal. And I wanted to discuss that in the other thread, but you make it very hard.
I meant it literally. A set of questions should be answered. That's all. And I actually went on and said that it should be blocked "If there's some downside that definitely outweighs the benefit [...]". That should imply that without such a heavy downside, people can go on.
I don't think we're going to refuse a platform right now simply because it has blobs.
Nobody brought that up. What are you referring to?
See your above statement. If you'd said "at the start of a new project, we'd like to get the vendor to let us know what the blob situation looks like", sure. But the way it was phrased of "Before the first commit can be merged" says to me that you don't want to allow the platform to even get started in coreboot until you (or someone) is satisfied by the blob situation for the new platform. It's not like that discussion is going to be quick either. Blobs are ALWAYS contentious, which I'm fine with. I'm just not fine with blocking the progress of people who are trying to do their best to get their work done simply because we don't like blobs.
Well, it should matter more what it says and not what it says to you. Please, please don't interpret something into it that wasn't written.
I wrote nothing about any satisfactory requirements. Beside that it shouldn't be a definite downfall.
My reason to say "before the first commit can be merged" was to make sure that it's not forgotten to answer the questions or even attempted to skip the discussion. New platforms are often added by inexperienced people who don't see the value in an early dis- cussion because they don't know what shitstorm they have to expect when they skip it.
I'm not sure what coreboot would look like right now if we'd started refusing blobs when the required blobs started appearing, but it definitely wouldn't have many modern platforms.
That's a very hypothetical, IMO wrong statement. "definitely" is a very strong word there. Also, what's a "required blob" anyway? Most of the blobs in coreboot are not required but politically desired. As an ex- perienced coreboot developer who has written fully open-source platform support in the past, I would expect this to have happened: We'd have less ARM platforms in the tree because those were added for Chromebooks with little interest from other folks. On the x86 end, we'd be behind about a year compared to the support we have today, as other companies who rely less on the silicon vendor's blessing might have done the job. The community would look much different. Instead of many developers struggling to bring blobs up, we'd have less but much better experienced developers who still understand the hardware.
Of course we'll never know which scenario would have been more likely. But it's been almost ten years, a lot could have happened. Imagine coreboot would have been FSP free, maybe even AMD would have been more open to a free software solution. FWIW, FSP encourages a lot of people to put more and more code into blobs. IMO we are stuck in a corner, and you want us to stay there as calm as possible.
Just because it didn't happen doesn't mean it's simply hypothetical. ChromeOS pushing to not use the FSP didn't make intel reconsider it. AMD introduced the binary PI because they no longer had the resources to support open sourcing it. I'm sure what would have happened, and so is Patrick, when he said that coreboot would be gone if we had refused blobs.
You say Intel and AMD. You seem to forget that the best native implementations in coreboot were not written by them. Yes, Intel and AMD wouldn't have opened up their code, sure. But that might be better. It would imply higher code quality and better under- standing of the hardware in the community.
You make it sound like people outside of these companies don't want to write code for their chips. I've seen some tendency by companies to expect the silicon vendors to write the code. Would you say that this reflects the opinion of individuals in the community? I have witnessed the opposite.
And I think it's very presumptuous of you to assume that you know what it is that I want. "unfortunate reality that allowing these blobs is a requirement" and the part that you removed from the end of my email in your response where I talk about the work that's being done to try to get vendors to open their codebases, are *NOT* me saying that I want you to stay stuck in the corner with all the blobs, let alone being calm.
Well, even with the mail I'm responding to right now you have questioned the value to discuss blob matters early. It makes me believe that you don't want people to discuss these matters, hence my "stay [..] calm".
I'm actually working with vendors to get them to open their code, and have been doing so for a LONG time, thank you very much.
It's nice that you are doing this. And I know you mentioned earlier that you need more companies asking for it. But how is that going to happen if we don't keep discussing things in public?
We all agree that we don't like adding more proprietary binaries, but there are times when a binary needs to be closed for a time until the platform is released such as with the PSE. This should be acceptable, so long as the promise is actually followed through upon. If not, the company making that promise loses credibility. Unfortunately, that's not always a great motivator. Maybe the coreboot organization & SFC can enter into a contract that specified a rough timeframe that the firmware would be open sourced. Hopefully that would be enough of a guarantee.
You know that the PSE is an Intel thing and still talk about credibility?
And I talked about ways to try to make them follow through on their promises.
Do you have any idea what is going on around their blobs? There are even claims in our documentation today that can't be explained and look like very weak excuses for the simple fact: The blob interface was done like this because Intel wanted it and all promises were only made to get the patch in. That Intel lost its credibility on the matter is one reason why it is hard to get things like the PSE support added. I think we need a better process so the developers tasked with such things don't suffer. And they should never be in a position that needs them to make promises. Individuals can't make promises on behalf of a huge company, that would be gambling, IMO, and we would never get an official, written promise anyway. So please forget about promises.
sorry, let me repeat this from my last email, maybe you missed it: Maybe the coreboot organization & SFC can enter into a contract that specified a rough timeframe that the firmware would be open sourced. Hopefully that would be enough of a guarantee.
That would be quite awesome. But it's a huge "maybe". I ignored it because I don't believe in fairy tales. Or more accurately, my ex- perience with Intel has completely disillusioned myself. Even if they signed such a contract I would only believe it the day that they actually publish something. And until that day I'd have to act as if they hadn't signed such contract. The history of Intel blobs is a history of broken promises, I will never again hope for anything in that direction.
Simply refusing to accept the binaries *only hurts us*, most companies will be probably happy using Slimboot or TianoCore. Making things difficult to work with coreboot only makes it easier to show why something shouldn't be open and why the chip vendors shouldn't work with coreboot. I cant tell you how many times I've heard that the reason coreboot wasn't used or wasn't upstreamed was that it takes too long to get changes into coreboot.
Again not sure why you bring that up? I started a thread to make things easier. Why do you want to make it harder?
CB:55367 was pushed on June 9th. It's 5 months later. Intel hasn't been able to get it merged yet. Sure, we're not outright saying they can't get it in, but in effect, that's what's happening.
Yes, 5 months stalled, because nobody told them that we should discuss it. Hence my proposal to discuss things early. You don't like it? Please propose something better.
Do you disagree? Do you think that this is easy for the developers who are told by intel to get the patches merged? The coreboot project is difficult to work with. That's just the truth, whether you see it or not. I'm not making it any harder by having this discussion with you.
No, you are not making it harder. But you derailed my attempt to discuss to make it better.
Nico
Nov 7, 2021, 04:13 by nico.h@gmx.de:
On 07.11.21 00:11, Martin Roth wrote:
CB:55367 was pushed on June 9th. It's 5 months later. Intel hasn't been able to get it merged yet. Sure, we're not outright saying they can't get it in, but in effect, that's what's happening.
Yes, 5 months stalled, because nobody told them that we should discuss it. Hence my proposal to discuss things early. You don't like it? Please propose something better.
Okay, I'm removing the rest of this conversation now that you've agreed that you are actually talking about blocking platforms because of blobs.
We both agree that we want things to be discussed. Let's start the conversation early, that's great. You want to block things until you're satisfied. I disagree. Blocking patches just makes companies work on a fork, and actually prevents the progress we all want. We both want coreboot to stay alive, and unfortunately, right now, that means that we're stuck dealing with blobs on the platforms that require them. If someone in a country that allows reverse engineering wants to work on replacing the blobs, that's great. Until then, they're the unfortunate reality.
The advantage to putting things into the coreboot tree is that EVERYONE needs to work to not break other people's stuff with their changes. The coreboot community includes intel and AMD, and Google, and Secunet along with the people who don't work for any company. It's not any one individual's job, it's everyone's.
If someone doesn't want to deal with the blobs, then just don't. You can't break those platforms, but you also don't have to work on them. Just don't use those platforms.
As Ron said, "coreboot is best effort, not perfection."
Let's try to work together on making things better
Martin
Dear Martin,
Am 08.11.21 um 19:38 schrieb Martin Roth:
Nov 7, 2021, 04:13 by nico.h@gmx.de:
On 07.11.21 00:11, Martin Roth wrote:
CB:55367 was pushed on June 9th. It's 5 months later. Intel hasn't been able to get it merged yet. Sure, we're not outright saying they can't get it in, but in effect, that's what's happening.
Yes, 5 months stalled, because nobody told them that we should discuss it. Hence my proposal to discuss things early. You don't like it? Please propose something better.
Okay, I'm removing the rest of this conversation now that you've agreed that you are actually talking about blocking platforms because of blobs.
Sorry, where did you read that? I didn’t. Please keep in mind, that English is not the native language for everyone, so if there is something unclear, please ask to clarify.
We both agree that we want things to be discussed. Let's start the conversation early, that's great. You want to block things until you're satisfied. I disagree. Blocking patches just makes companies work on a fork, and actually prevents the progress we all want. We both want coreboot to stay alive, and unfortunately, right now, that means that we're stuck dealing with blobs on the platforms that require them. If someone in a country that allows reverse engineering wants to work on replacing the blobs, that's great. Until then, they're the unfortunate reality.
Again, I think we misunderstand each other.
It’s about getting change-sets reviewed properly, and that includes how they fit into the project. And yes, (proprietary) blobs have proven to be a huge problem in the past putting a big burden on the community. So it’s only valid to review these patches properly. And now we are back to a general problem, unrelated to blobs. How to get the focus of the right reviewers to the right change-sets. I noticed the change-set by chance, and should have asked to discuss this on the list already in July. There is also a two month gap, when nothing happened. Again, I’d say, asking on the list helps in such cases. After attention was raised, developers reviewed the change-set, and it improved a lot.
The advantage to putting things into the coreboot tree is that EVERYONE needs to work to not break other people's stuff with their changes. The coreboot community includes intel and AMD, and Google, and Secunet along with the people who don't work for any company. It's not any one individual's job, it's everyone's.
That is how it should work. I do not have statistics at hand, but besides a handful of people, it’s not really happening, as we only have very few developers, who understand the whole project well enough to do and review certain changes.
If someone doesn't want to deal with the blobs, then just don't. You can't break those platforms, but you also don't have to work on them. Just don't use those platforms.
Excuse my ignorance, but reading some of the change-sets, that is not the reality. You also have to deal with the platforms using blobs, if you want to do tree wide improvements.
As Ron said, "coreboot is best effort, not perfection."
That’s a good statement, but as perfection is a long way ahead, all the discussion here revolves around the best effort.
Let's try to work together on making things better
Yes. It’s my impression, a big part of the discussion was about two misunderstandings. I’d still say, it’d be great, if Nico drafted changes for the binary policy, so we can discuss something concrete.
Kind regards,
Paul
Dear coreboot project,
this discussion heated up and escalated considerably, to the point where things got personal. I have since put Nico and Martin into temporary moderation for this mailing list, in an attempt to get the temperature down at least within the project.
The timing of me doing so led to statements about Nico going through without a chance for Nico to react. To avoid further escalation, I offered to voice Nico's disagreement so that the public record doesn't end with uncontested assertions about him.
Specifically, Martin wrote that Nico "agreed that [he is] actually talking about blocking platforms because of blobs", and also that Nico wants "to block things until [he is] satisfied."
Nico objects to both assertions.
I hope that that these two valued long-time contributors find a way to set aside their differences and reconcile, but I'm not sure that the public is the right venue to work on that.
Best regards, Patrick Georgi
-
Martin Roth -
Nico Huber -
Patrick Georgi -
Paul Menzel