Nov 6, 2021, 05:21 by [email protected]: > On 05.11.21 18:15, Martin Roth via coreboot wrote: > >> Nov 4, 2021, 05:24 by [email protected]: >> >>> 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 [email protected]: 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 _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
