Hi coreboot community,
a recent yet-another-blob occurrence reminded me that I wanted to write about the matter for a long time.
Every few months, it seems (if not, more often), a new blob is introduced to coreboot. Alas, this is often hidden to the last minute, creating unnecessary friction and unfortunate, set-in- stone solutions that haunt us for the years to come.
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.
IMO, just answering all questions shouldn't suffice to unlock the merge. If there's some downside that definitely outweighs the benefit of adding the new platform, it should be blocked until the blob situation can change. For instance, we had in the past blobs that needed to be cus- tomized under NDA per board. Something like that doesn't seem to be useful for a free-software project.
What do you think?
Nico
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.
Some ideas for questions from the top of my head:
o Why a blob instead of coreboot integration? (What surprised me in the past: Sometimes it's just that the blob was already written (e.g. graphics init on Intel). And people preferred already written proprietary code over open-source contribution.)
o What kind of blob is it? e.g. - resides in the same storage medium as coreboot - is loaded but not run by coreboot + is run by another processor not used by coreboot + is run later on the same processor as coreboot - is loaded and run by coreboot (questions below mostly apply to this case)
o Was the blob designed for coreboot? or is it merely compatible enough?
o Was the blob designed based on input from - the coreboot community? - any of its members?
o Is it publicly documented what the blob does?
o Is NDA documentation available?
o Does the silicon vendor allow an open-source implementation based on the available documentation?
o Does the silicon vendor allow an open-source implementation based on their undisclosed reference code?
o Does the silicon vendor allow an alternative blob implementation based on the available documentation / reference code? (Rationale: Silicon vendors often dictate the interface of their blobs, what their blobs do (sometimes much much much more than necessary) etc. The effort to integrate the original blobs might outweigh the effort to write new ones.)
o Would the silicon vendor be interested to work together with the community on an open, coreboot-native implementation?
o Would the silicon vendor be interested to work together with members of the community under NDA on an alternative blob implementation?
o Is the blob's interface (completely) documented? (IMO, something we should demand, blob documentation (e.g. FSP) is often much too thin for long-term maintenance.)
o Is the blob's documentation sufficient to integrate it into coreboot without further references (e.g. looking into the blob's source code)?
o Will there be public binary releases of the blob?
- Will there be updates to the binary releases if any issues occur with coreboot?
- Will there be security updates? If so, for how long?
- Will it be allowed to fix bugs in the binaries if the silicon vendor doesn't do it?
- Will it be allowed to fix integration/maintenance issues in the binaries if the silicon vendor doesn't do it?
I guess that's enough to get the discussion started. I hope there will be many more questions, and that those will be answered in the future :)
Nico
Nico wrote...
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.
Some ideas for questions from the top of my head:
That seems like a long list of questions and so my question in return would be how practical is it?
Taking EC firmware as an example, in many situations the short answer is “it resides in the same binary image as coreboot and is a blob because that is all there is”. Based on your list of questions I’m not convinced that would be sufficient to get it merged.
-Andy.
On Wed, Oct 20, 2021 at 8:53 AM Andy Pont andy.pont@sdcsystems.com wrote:
Nico wrote...
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.
Some ideas for questions from the top of my head:
That seems like a long list of questions and so my question in return would be how practical is it?
Taking EC firmware as an example, in many situations the short answer is “it resides in the same binary image as coreboot and is a blob because that is all there is”. Based on your list of questions I’m not convinced that would be sufficient to get it merged.
Why would we be adding EC blobs to the coreboot repo?
-Andy.
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 20.10.21 16:07, Matt DeVillier wrote:
On Wed, Oct 20, 2021 at 8:53 AM Andy Pont andy.pont@sdcsystems.com wrote:
Nico wrote...
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.
Some ideas for questions from the top of my head:
That seems like a long list of questions and so my question in return would be how practical is it?
Taking EC firmware as an example, in many situations the short answer is “it resides in the same binary image as coreboot and is a blob because that is all there is”. Based on your list of questions I’m not convinced that would be sufficient to get it merged.
Why would we be adding EC blobs to the coreboot repo?
I think there could be situations where it makes sense. For instance, if coreboot had to load an update blob into the EC and that has to reside in CBFS.
Nico
Accidentally responded off the mailing list initally. :-/
Oct 20, 2021, 08:07 by matt.devillier@gmail.com:
On Wed, Oct 20, 2021 at 8:53 AM Andy Pont andy.pont@sdcsystems.com wrote:
Nico wrote...
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:
...
We already have a list of things required to go in with binaries checked into the blobs repo. I personally don't have any objection with updating the document if more things are needed.
https://review.coreboot.org/plugins/gitiles/blobs/+/refs/heads/master/README...
We could also add a jenkins build that helps to verify that these are met - at least check that any commit of a binary updates the release notes. Maybe use a machine-parsable template similar to board_info in the coreboot mainboards directory. This could contain all of the information required.
Taking EC firmware as an example, in many situations the short answer is “it resides in the same binary image as coreboot and is a blob because that is all there is”. Based on your list of questions I’m not convinced that would be sufficient to get it merged.
Why would we be adding EC blobs to the coreboot repo?
I'm assuming we're talking about the coreboot blobs repo, not the actual coreboot repo.
The EC firmware sometimes runs out of the boot rom, so the final firmware must also contain the EC image. I realize that it's a point of contention in the coreboot community whether the coreboot build process should produce a complete binary. Some feel that it's more appropriate for users to add any external bits outside of the coreboot build. If we're going to allow binaries into the coreboot build process though, I don't see a reason to exclude EC binaries.
If any EC images were added, they'd need to be licensed as being redistributable before they could be added. They can't just be pulled out of someone else's image and hosted in the coreboot blobs repo.
On 20.10.21 20:22, Martin Roth via coreboot wrote:
Accidentally responded off the mailing list initally. :-/
Oct 20, 2021, 08:07 by matt.devillier@gmail.com:
On Wed, Oct 20, 2021 at 8:53 AM Andy Pont andy.pont@sdcsystems.com wrote:
Nico wrote...
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:
...
We already have a list of things required to go in with binaries checked into the blobs repo.
Sorry if that wasn't clear. I'm talking about coreboot support for new, blobbed platforms in general. I don't care that much about the blobs repo. Every time a new platform that requires blobs is added upstream, the community gets to maintain the code. And that often results to some degree in suffering.
Hence, I'd like to encourage to get some things sorted out before the support is added. Also to avoid the usual friction when somebody gets paid to add a blob and doesn't even know that there are people that might want to talk about it.
Nico
Hi Andy,
On 20.10.21 15:53, Andy Pont wrote:
Nico wrote...
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.
Some ideas for questions from the top of my head:
That seems like a long list of questions and so my question in return would be how practical is it?
splendid! Your reaction shows how much we need such questions: Without pushing us to reflect about them, people may not even consider alter- natives. I think it's very practical.
Taking EC firmware as an example, in many situations the short answer is “it resides in the same binary image as coreboot and is a blob because that is all there is”.
Why stop at the short answer? I have to admit, you'd have to replace `silicon vendor` with `ODM`, or whoever supplies the blob, but otherwise how do the questions not apply? Don't you want to consider alternatives? People did before and succeeded pretty much. Don't you want bugfixes?
Even if you'd have to answer many questions with `no (the ODM doesn't allow / is not interested`, that's at least something that nobody has to investigate later. Currently almost nobody knows anything about the blobs we use in coreboot and everybody has to start considerable inves- tigations to answer simple questions like "will there be an update?". Why not at least try to answer these questions honestly up front?
Based on your list of questions I’m not convinced that would be sufficient to get it merged.
No. If you are confronted with a list of questions and simply choose to ignore them, why would that be sufficient?
Nico
Dear Nico,
On 20.10.21 14:24, Nico Huber wrote:
a recent yet-another-blob occurrence reminded me that I wanted to write about the matter for a long time.
Every few months, it seems (if not, more often), a new blob is introduced to coreboot. Alas, this is often hidden to the last minute, creating unnecessary friction and unfortunate, set-in- stone solutions that haunt us for the years to come.
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.
IMO, just answering all questions shouldn't suffice to unlock the merge. If there's some downside that definitely outweighs the benefit of adding the new platform, it should be blocked until the blob situation can change. For instance, we had in the past blobs that needed to be cus- tomized under NDA per board. Something like that doesn't seem to be useful for a free-software project.
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.
It’d be great, if you could extend the coreboot’s current binary policy v1.0 [1].
Kind regards,
Paul
[1]: https://review.coreboot.org/plugins/gitiles/blobs/+/f836ff362b0411ab6c9e580b...
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. I don't think we're going to refuse a platform right now simply because it has 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.
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.
Every company is in business to make money in some way. If there's no profit to be made doing something, they're going to have a hard time keeping their doors open. So long as they don't see a financial benefit to being open-source, they're simply not going to do it. To make this happen, we need more companies requesting that the chip vendors open their proprietary blobs.
Being more involved in the planning phase would be great, and obviously there are companies contributing to coreboot who ARE involved in these discussions. Expecting companies to discuss their plans for future chips in the open probably isn't going to happen.
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.
These things said, I think we can come up with solutions to make things easier. Ron suggested several years ago that we could enable Kconfig to only show the platforms with the amount of binaries that people are comfortable with. Maybe we need to look into that more. We can require that the soc/cpu/chipset Kconfig screens display what blobs are required. We can push to get anything we can moved from the blobs into coreboot. We can, and we are, pushing the vendors to be more open-source friendly, and we're finally starting to see some more and more people at these companies buying into this.
Martin
I'd like to get back to a rating system. There's a really simple measure that I've never seen improved upon, namely, for a given firmware image, what fraction of the bits in that image come from open source code?
e.g., the KGPE-D16 would get a 100%, and a typical laptop would get 0%.
This is a really easy number to compute, automatically, and might even be an option to cbfstool or a ROM tool.
Marketing types are sensitive to numbers like this: we could prominently display these numbers on coreboot.org
ron
On Fri, Nov 5, 2021 at 10:16 AM Martin Roth via coreboot coreboot@coreboot.org 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. I don't think we're going to refuse a platform right now simply because it has 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.
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.
Every company is in business to make money in some way. If there's no profit to be made doing something, they're going to have a hard time keeping their doors open. So long as they don't see a financial benefit to being open-source, they're simply not going to do it. To make this happen, we need more companies requesting that the chip vendors open their proprietary blobs.
Being more involved in the planning phase would be great, and obviously there are companies contributing to coreboot who ARE involved in these discussions. Expecting companies to discuss their plans for future chips in the open probably isn't going to happen.
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.
These things said, I think we can come up with solutions to make things easier. Ron suggested several years ago that we could enable Kconfig to only show the platforms with the amount of binaries that people are comfortable with. Maybe we need to look into that more. We can require that the soc/cpu/chipset Kconfig screens display what blobs are required. We can push to get anything we can moved from the blobs into coreboot. We can, and we are, pushing the vendors to be more open-source friendly, and we're finally starting to see some more and more people at these companies buying into this.
Martin
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Am Fr., 5. Nov. 2021 um 19:11 Uhr schrieb ron minnich rminnich@gmail.com:
e.g., the KGPE-D16 would get a 100%
except for the VGABIOS.
Marketing types are sensitive to numbers like this: we could prominently display these numbers on coreboot.org
They're also pretty sensitive about any kind of mistake (or as they'd put it: false statement) you make.
Patrick
On 05.11.21 19:10, ron minnich wrote:
I'd like to get back to a rating system. There's a really simple measure that I've never seen improved upon, namely, for a given firmware image, what fraction of the bits in that image come from open source code?
e.g., the KGPE-D16 would get a 100%, and a typical laptop would get 0%.
This is a really easy number to compute, automatically, and might even be an option to cbfstool or a ROM tool.
Marketing types are sensitive to numbers like this: we could prominently display these numbers on coreboot.org
I think it's a good idea. Not what I wanted to discuss though ;) It would be nice for marketing and end users. But I'm currently much more concerned with our development experience.
Very often, I see amidst the many patches that bring up a new platform, a tiny "bomb" that adds support for another kind of blob. When that's the first time a new kind of blob is mentioned, discussions around it get very intense quickly and can stall a project that was otherwise progressing well. Not to mention (mild) attacks on IRC I've seen.
So what I proposed was to give people some guidance how to avoid or defuse such a "bomb". That could be answering questions in advance, could be something else.
Nico
Am Fr., 5. Nov. 2021 um 18:16 Uhr schrieb Martin Roth via coreboot < coreboot@coreboot.org>:
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. I don't think we're going to refuse a platform right now simply because it has 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.
It would be dead: while there are still a few folks carefully maintaining i945 and GM45 in this reality, I'm not sure they would have done so in that other reality where there was no help maintaining the payloads (and so coreboot-compatible seabios, tianocore, grub, filo, ... would all be on their plate as well)
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.
There's a UPD called PchPseEnable - I wonder what it does if you set to it 0? ;-)
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 the SFC (coreboot org is not a separate legal entity). We could ask and I suppose it would further the SFC's missions (more Software Freedom!), but it's not something they already do routinely, and last I heard they're pretty swamped with work already. That said: If we ask, the worst they can do is say "no", right?
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.
Compared to pretty much every other project (including high profile stuff like Linux, and don't get me started on the mess that is u-boot forks), coreboot is doing a relatively good job at coalescing developments upstream.
These things said, I think we can come up with solutions to make things
easier. Ron suggested several years ago that we could enable Kconfig to only show the platforms with the amount of binaries that people are comfortable with. Maybe we need to look into that more.
It's work - and lots of it - to get this to the granularity needed to satisfy everyone. And then it needs a dedicated "librarian" role to keep all new development categorized properly. Much as I like the idea, we're already spread thin so I just don't see that. (I guess that's a complicated way of saying: contributions desired!)
(And then it also differs by desired feature set: while I don't know who in their right mind would use TXT, SGX or any of the other toys pretending to improve security, apparently there are such folks, and on some platforms enabling these means "optional blobs". So the set of platforms differs by "blob level" _and_ feature set.)
We can require that the soc/cpu/chipset Kconfig screens display what blobs
are required.
Few people see those screens.
We can push to get anything we can moved from the blobs into coreboot. We
can, and we are, pushing the vendors to be more open-source friendly, and we're finally starting to see some more and more people at these companies buying into this.
This is something I can only emphasize: there is movement in the right direction - and there's also a struggle to not let things slip back, but lots of these things happen behind closed doors. "Trust us" is always a hard sell, but if you don't trust us, look elsewhere and see how much better it gets?
Patrick
On 05.11.21 19:39, Patrick Georgi via coreboot wrote:
Am Fr., 5. Nov. 2021 um 18:16 Uhr schrieb Martin Roth via coreboot < coreboot@coreboot.org>:
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. I don't think we're going to refuse a platform right now simply because it has 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.
It would be dead: while there are still a few folks carefully maintaining i945 and GM45 in this reality, I'm not sure they would have done so in that other reality where there was no help maintaining the payloads (and so coreboot-compatible seabios, tianocore, grub, filo, ... would all be on their plate as well)
That seems an odd assessment. Did you confuse blobs that are "required" in coreboot with blobs that sit in the same storage medium (e.g. ME firmware)? It also seems that you underestimate the individuals in the community.
Nico
Nov 6, 2021, 05:49 by nico.h@gmx.de:
On 05.11.21 19:39, Patrick Georgi via coreboot wrote:
It [coreboot] would be dead: while there are still a few folks carefully maintaining i945 and GM45 in this reality, I'm not sure they would have done so in that other reality where there was no help maintaining the payloads (and so coreboot-compatible seabios, tianocore, grub, filo, ... would all be on their plate as well)
That seems an odd assessment. Did you confuse blobs that are "required" in coreboot with blobs that sit in the same storage medium (e.g. ME firmware)? It also seems that you underestimate the individuals in the community.
I don't understand your statement that patrick is underestimating the individuals in the community. Are you saying that people would have worked around the blobs? If so, then why haven't we seen that code. We'd all love it.
Could you explain?
Thanks. Martin
On 07.11.21 00:15, Martin Roth wrote:
Nov 6, 2021, 05:49 by nico.h@gmx.de:
On 05.11.21 19:39, Patrick Georgi via coreboot wrote:
It [coreboot] would be dead: while there are still a few folks carefully maintaining i945 and GM45 in this reality, I'm not sure they would have done so in that other reality where there was no help maintaining the payloads (and so coreboot-compatible seabios, tianocore, grub, filo, ... would all be on their plate as well)
That seems an odd assessment. Did you confuse blobs that are "required" in coreboot with blobs that sit in the same storage medium (e.g. ME firmware)? It also seems that you underestimate the individuals in the community.
I don't understand your statement that patrick is underestimating the individuals in the community. Are you saying that people would have worked around the blobs? If so, then why haven't we seen that code. We'd all love it.
Could you explain?
That's so easy to answer that I wonder if you are trolling me? Long story short, if a project is cluttered with blobs, you can't expect people to go on as if that didn't happen.
When people are employed to work on blob support instead of native implementations, they don't have the time to work on the latter. Your scenario was "we'd started refusing blobs when the required blobs started appearing". In such a reality, I assume less people would have been employed to work on blob support. IIRC, there was a time when you couldn't hire anyone for coreboot work because a certain blob supporter already hired all of them.
Also, the upstream project became unfriendly towards solutions that are not carried by the respective silicon vendor. I've witnessed that first hand. For instance, when the first ramstage blobs were added, the whole codebase for Intel silicon was kind of forked inside our own repository, digging a deep ditch between the existing native code and the support for newer platforms. In such an environment, it becomes more unlikely that individuals add coreboot-native code. Somebody has spent months to overcome that ditch btw. and IIRC that was to prepare for some coreboot-native implementation that is already working.
There's also a general reluctance to expect to support a project with free software that has shown that it doesn't take the GPL seriously.
Nico
Nov 7, 2021, 04:29 by nico.h@gmx.de:
On 07.11.21 00:15, Martin Roth wrote:
Nov 6, 2021, 05:49 by nico.h@gmx.de:
It also seems that you underestimate the individuals in the community.
I don't understand your statement that patrick is underestimating the individuals in the community. Are you saying that people would have worked around the blobs? If so, then why haven't we seen that code. We'd all love it.
Could you explain?
That's so easy to answer that I wonder if you are trolling me?
Nope. You say in a following email that if there's a question about what you mean, we should ask you, but then you wonder if I'm trolling you when I ask for an explanation? What's going on?
Long story short, if a project is cluttered with blobs, you can't expect people to go on as if that didn't happen.
Sure we can. It actually gives people something to start with and replace.
When people are employed to work on blob support instead of native implementations, they don't have the time to work on the latter. Your scenario was "we'd started refusing blobs when the required blobs started appearing". In such a reality, I assume less people would have been employed to work on blob support. IIRC, there was a time when you couldn't hire anyone for coreboot work because a certain blob supporter already hired all of them.
I'm not sure who you're referring to as a blob supporter, but Google's never wanted blobs. Sage didn't either, they just needed anything to stay alive. The blob support has all been the chip vendors. And I think until Felix and Marshall went to AMD, the only other person involved in the coreboot community who went to a chip vendor directly was MrNuke when he went to intel. Everyone else has generally had to train people to work on coreboot. (Even Sage, with the exception of Marc Jones.)
Also, the upstream project became unfriendly towards solutions that are not carried by the respective silicon vendor. I've witnessed that first hand. For instance, when the first ramstage blobs were added, the whole codebase for Intel silicon was kind of forked inside our own repository, digging a deep ditch between the existing native code and the support for newer platforms. In such an environment, it becomes more unlikely that individuals add coreboot-native code. Somebody has spent months to overcome that ditch btw. and IIRC that was to prepare for some coreboot-native implementation that is already working.
I don't recall anyone being unfriendly towards solutions not done by the chip vendor. I agree that we haven't seen much, because of a lack of documentation and the difficulty in doing those ports. But could you point me to an example of a time when someone wanted to do a CPU/SOC port that coreboot refused because it wasn't done by the vendor?
As far as I know everyone wants to move as much out of the blobs and back into coreboot as we can get.
There's also a general reluctance to expect to support a project with free software that has shown that it doesn't take the GPL seriously.
Again, I'm not entirely certain what you mean here.I'm guessing you're talking about the "no linking" clause? We've talked to the lawyers at the SFC, and they haven't said that there's any issue with what's being done. Or are you saying that the SFC doesn't take the GPL seriously? Maybe there are differences of opinions on what taking the GPL seriously means?
Are things that use BSD, MIT, or other non-copyleft licenses not to be taken seriously as free software? You ask to be taken literally, but I'm generally left being confused by your statements. I apologize.
Feel free to respond if you want, but I think this is yet another place where we just won't agree. I definitely don't like the blobs, but I really don't see any world in which simply refusing them would have had a good outcome for the coreboot project.
I'll leave this thread alone after this email.
Regards, Martin
On 08.11.21 19:38, Martin Roth wrote:
Nov 7, 2021, 04:29 by nico.h@gmx.de:
On 07.11.21 00:15, Martin Roth wrote:
Nov 6, 2021, 05:49 by nico.h@gmx.de:
It also seems that you underestimate the individuals in the community.
I don't understand your statement that patrick is underestimating the individuals in the community. Are you saying that people would have worked around the blobs? If so, then why haven't we seen that code. We'd all love it.
Could you explain?
That's so easy to answer that I wonder if you are trolling me?
Nope. You say in a following email that if there's a question about what you mean, we should ask you, but then you wonder if I'm trolling you when I ask for an explanation? What's going on?
Because it's so simple to explain. At least when one knows what is going on. I may have missed that you don't.
Long story short, if a project is cluttered with blobs, you can't expect people to go on as if that didn't happen.
Sure we can. It actually gives people something to start with and replace.
When people are employed to work on blob support instead of native implementations, they don't have the time to work on the latter. Your scenario was "we'd started refusing blobs when the required blobs started appearing". In such a reality, I assume less people would have been employed to work on blob support. IIRC, there was a time when you couldn't hire anyone for coreboot work because a certain blob supporter already hired all of them.
I'm not sure who you're referring to as a blob supporter, but Google's never wanted blobs. Sage didn't either, they just needed anything to stay alive. The blob support has all been the chip vendors. And I think until Felix and Marshall went to AMD, the only other person involved in the coreboot community who went to a chip vendor directly was MrNuke when he went to intel. Everyone else has generally had to train people to work on coreboot. (Even Sage, with the exception of Marc Jones.)
Since about 2014 all the Intel-based Chromebooks use an *optional* blob for graphics init, even though the hardware is *publicly* documented virtually to the last bit. There is no pressure whatsoever from Intel. These blobs are used willingly. As Google seems responsible for the firmware, I have to assume they are supporting blobs. Welcome to reality, Martin. As this happens right under your nose, I can't trust you when you say everybody wants to get rid of the blobs. Well, trust may be the wrong word, I think you don't have a clue.
And that's just the area I'm an expert in. I don't know how many more cases there are where blobs are simply used because they exist. Closing our eyes doesn't help. We need to keep talking about these things.
Also, the upstream project became unfriendly towards solutions that are not carried by the respective silicon vendor. I've witnessed that first hand. For instance, when the first ramstage blobs were added, the whole codebase for Intel silicon was kind of forked inside our own repository, digging a deep ditch between the existing native code and the support for newer platforms. In such an environment, it becomes more unlikely that individuals add coreboot-native code. Somebody has spent months to overcome that ditch btw. and IIRC that was to prepare for some coreboot-native implementation that is already working.
I don't recall anyone being unfriendly towards solutions not done by the chip vendor. I agree that we haven't seen much, because of a lack of documentation and the difficulty in doing those ports. But could you point me to an example of a time when someone wanted to do a CPU/SOC port that coreboot refused because it wasn't done by the vendor?
I wasn't referring to any full platform support. Around 2014 coreboot on Intel platforms was effectively dead for anyone but a few select companies that Intel chose to talk to. There were two competing blobs to bring up Broadwell, neither of them was redistributable so many folks were shut out from coreboot development. Somewhere around the FSP for Skylake / Kaby Lake things got better, blob-access wise, but the existing platform code was tailored to Chromebooks and any attempt to fix it was blocked by the fear of breaking something. I tried to, but nobody took the time to answer the simplest questions about the boards in the tree. When somebody else took the burden to review my patches, I got bullied by Intel and Google employees when something broke. I'm not mad at anyone for this. I simply assume that some people's social skills got crushed under the corporate pressure.
As far as I know everyone wants to move as much out of the blobs and back into coreboot as we can get.
Well, definitely not everyone, see above.
There's also a general reluctance to expect to support a project with free software that has shown that it doesn't take the GPL seriously.
Again, I'm not entirely certain what you mean here.I'm guessing you're talking about the "no linking" clause? We've talked to the lawyers at the SFC, and they haven't said that there's any issue with what's being done. Or are you saying that the SFC doesn't take the GPL seriously? Maybe there are differences of opinions on what taking the GPL seriously means?
Sorry let me try to explain.
There are permissive and copy-left licenses. The GPL is one of the latter kind. Permissive licenses are of the "I don't care what you do with the code" kind. For copy-left licenses it is assumed that when somebody takes free software, they also give free software back. It's kind of the payment for the free software, we don't want money, we want more free software. Intel, for instance, does not give free software back. They don't pay. Many other entities do. They don't. Our leader- ship accepts that. Hence I see it as that the project doesn't take the GPL seriously.
Are things that use BSD, MIT, or other non-copyleft licenses not to be taken seriously as free software?
I don't understand the question. Maybe it's answered above.
You ask to be taken literally, but I'm generally left being confused by your statements. I apologize.
Feel free to respond if you want, but I think this is yet another place where we just won't agree. I definitely don't like the blobs, but I really don't see any world in which simply refusing them would have had a good outcome for the coreboot project.
No refusing them doesn't help. But writing free software where we can could. Please start with that.
Nico
Am So., 7. Nov. 2021 um 12:29 Uhr schrieb Nico Huber nico.h@gmx.de:
There's also a general reluctance to expect to support a project with free software that has shown that it doesn't take the GPL seriously.
General reluctance by whom? I just don't see that, instead I see tons of activity by a very diverse crowd of people (contributing individually or for companies of all sizes). On the other hand, where's the coreboot fork/branch/variant/you-name-it that improves in "taking the GPL seriously"? Where are its contributors?
(There's Libreboot, but it specifically is not a platform bringup project: They strip coreboot of the things they dislike and then make the rest work as well as possible. More power to them, and if there are means to make these steps easier for them, I'd like to hear about it so we can work on that - we did that in the past. This also means that their relative lack of contributors is not to be held against them as independent development is not their mission.)
Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
On 08.11.21 19:57, Patrick Georgi wrote:
Am So., 7. Nov. 2021 um 12:29 Uhr schrieb Nico Huber nico.h@gmx.de:
There's also a general reluctance to expect to support a project with free software that has shown that it doesn't take the GPL seriously.
General reluctance by whom? I just don't see that, instead I see tons of activity by a very diverse crowd of people (contributing individually or for companies of all sizes). On the other hand, where's the coreboot fork/branch/variant/you-name-it that improves in "taking the GPL seriously"? Where are its contributors?
Personally, I have so far rejected the idea of a fork because I don't want to rip the community further apart. Maybe there are more people who think like me about it?
I've also stopped working on several coreboot topics because I didn't want leachers to benefit from it.
Nico
Nov 6, 2021, 05:49 by nico.h@gmx.de:
On 05.11.21 19:39, Patrick Georgi via coreboot wrote:
It [coreboot] would be dead: while there are still a few folks carefully maintaining i945 and GM45 in this reality, I'm not sure they would have done so in that other reality where there was no help maintaining the payloads (and so coreboot-compatible seabios, tianocore, grub, filo, ... would all be on their plate as well)
That seems an odd assessment. Did you confuse blobs that are "required" in coreboot with blobs that sit in the same storage medium (e.g. ME firmware)? It also seems that you underestimate the individuals in the community.
I don't understand your statement that Patrick is underestimating the individuals in the community. Are you saying that people would have worked around the blobs? If so, then why haven't we seen that code. We'd all love it.
Could you explain?
Thanks. Martin
On 05.11.21 18:15, Martin Roth via coreboot wrote:
Being more involved in the planning phase would be great, and obviously there are companies contributing to coreboot who ARE involved in these discussions. Expecting companies to discuss their plans for future chips in the open probably isn't going to happen.
I agree. My proposed set of questions, for instance, I'd ask to add this to the documentation and hence it would be published on Gerrit like all their other work. Not necessarily earlier (that would be a bonus ofc.) and the mailing list might be a too emotional forum considering that this would often be somebodies first post.
Nico
Dear Martin,
Am 05.11.21 um 18:15 schrieb Martin Roth:
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.
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. I don't think we're going to refuse a platform right now simply because it has 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.
As already answered by Nico, the proposal was never about prohibiting blobs.
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.
In this case it even turned out, that the PSE firmware uses Zephyr [1] is used, and that even for the contributor it wasn’t clear yet, how the release plans regarding the sources are.
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.
It would be really great, if that could be accomplished. Though it would be even better, if it were to happen without involving any lawyers.
Every company is in business to make money in some way. If there's no profit to be made doing something, they're going to have a hard time keeping their doors open. So long as they don't see a financial benefit to being open-source, they're simply not going to do it. To make this happen, we need more companies requesting that the chip vendors open their proprietary blobs.
Werner also brought up the make-money argument argument later, but I think it’s not very useful as it can be brought forward by both sides. The Google Chromebook market is huge, and companies are going to loose money, if they are not in it. Also companies spent a lot of resources on integrating blobs, which does not make them any money per se.
Being more involved in the planning phase would be great, and obviously there are companies contributing to coreboot who ARE involved in these discussions. Expecting companies to discuss their plans for future chips in the open probably isn't going to happen.
Sorry, this is the second misunderstanding in the discussion. After finding the PSE change-set, people in #coreboot discovered that it was presented at OSFC last year [1]. So it was publicly presented already. With Nico’s proposal in place, the PSE plans would also have been announced on the mailing list so feedback could have been gotten over a year ago from the community. The mailing list is not perfect, but the best option from all alternatives (conferences (not everybody there, nothing written), Gerrit change-set (overlooked if not added as reviewer/to Cc) or community meetings (not everybody there)).
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, it was never about rejecting blobs. But I also believe it shouldn’t be made too easy. FLOSS is a give an take, and, for example looking at time spent on reviewing also other contributions, a lot of companies are lacking.
These things said, I think we can come up with solutions to make things easier. Ron suggested several years ago that we could enable Kconfig to only show the platforms with the amount of binaries that people are comfortable with. Maybe we need to look into that more. We can require that the soc/cpu/chipset Kconfig screens display what blobs are required. We can push to get anything we can moved from the blobs into coreboot. We can, and we are, pushing the vendors to be more open-source friendly, and we're finally starting to see some more and more people at these companies buying into this.
In my opinion, this wouldn’t help with the problem at hand. It would be nice to have, but the benefit is small. Getting all parties involved on the mailing list, would be much better. Again, it’s not perfect, as the thread at hand shows, but still an improvement.
Kind regards,
Paul
[1]: https://www.zephyrproject.org/ [2]: https://cfp.osfc.io/osfc2020/talk/TNTFYV/ "Introducing open firmware development model for the Programmable Service Engine's in Intel Atom x6000E Series"
Hi again,
originally, I was hoping for a more comprehensive discussion about possible solutions for the friction created by late, undiscussed additions of blob-support code. Alas, that didn't happen, and my own proposal below was misunderstood. So I'll try now to provide some rationale.
First of all, I have to say that what I write is meant literally. Please don't try to imagine something between the lines. But if you really feel like you have to, please just ask how it was meant.
On 20.10.21 14:24, Nico Huber wrote:
a recent yet-another-blob occurrence reminded me that I wanted to write about the matter for a long time.
Every few months, it seems (if not, more often), a new blob is introduced to coreboot. Alas, this is often hidden to the last minute, creating unnecessary friction and unfortunate, set-in- stone solutions that haunt us for the years to come.
When I wrote "a new blob" I meant a new kind of blob. Not just another instance of a known blob with the same interface as an existing one, but rather something new that needs its own support code in coreboot.
My proposal: How about we set up some guidelines how to proceed when adding support for a new platform that requires any blobs?
IMO, such guidelines could help the developers who are tasked to add blob-support code. If we had a documented procedure, they would know what to do and could justify towards their employer, if necessary, that they need to do more than just pushing the code.
My vague idea is as follows: Before the very first commit for such a new platform can be merged, a
In my experience people often see such matters as rather unpleasant, so they tend to defer the discussion. They might even maneuver themselves into a corner because they are too afraid to bring it up. Having a clear rule when it should happen would preempt such a situation. When some- thing is unpleasant but necessary, it's better to be done with it, isn't it?
set of predefined, blob related questions (to be discussed) should be answered.
Beside exceptional bad-blob situations (see below), answering such questions should be enough to move forward, no matter the answer! We want people to be honest with their answers, hence we mustn't judge them for something their employer committed. (I thought that is obvious).
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.
This was my attempt to be clear about the scope. If we avoid to forget something from the beginning, we lower the risk to run into awkward situations later.
IMO, just answering all questions shouldn't suffice to unlock the merge. If there's some downside that definitely outweighs the benefit of adding the new platform, it should be blocked until the blob situation can change. For instance, we had in the past blobs that needed to be cus- tomized under NDA per board. Something like that doesn't seem to be useful for a free-software project.
Maybe this was a bad example. Anyway, I thought I was just stating the obvious: There are limits. For instance, even if we set up a procedure like the questions proposed, that should not allow to bring blob-support in that we wouldn't allow without such a procedure.
The whole proposal was meant to ease bringing code in that we can bring in. And if something was so bad that we really couldn't, it would allow us to realize that early enough before people wasted a lot of time. I see people suffering that are tasked to bring in new blob support. I want to help them. I think we could help them this way. Having some unpleasant questions answered would just be a nice side effect. ;)
Nico
Hi Nico.
I fully can understand your point of view in this discussion. Unfortunately, we do live in a real world with real companies that are business-driven. With this sidenote in context the world changes dramatically in this regard.
Your request for an early discussion whether this or that decision is acceptable pretends that a silicon vendor is willing to start this discussion fully open at a time where he by himself is not yet clear how the feature in question will finally look like (because once the vendor exactly know how it will look like it is set in stone [or silicon] already). Given this, communication on topics like this is very restricted, even inside a company. Everybody of us has experienced already that teams inside of a big company working on the same project but just on a different facet of it are often not aware of what is going on at the neighbors. Why is that? Well, this is IMHO because in our world more and more work is spread among viewer people. I do not see that this is evil-driven, it is just the lack of time the individuals have to get their job done in a fixed "24-hour-per-day-world". So I guess even if the companies would be willing to follow your approach to discuss things early we still will not get a perfect world. And discussing things implies that it will take some time to get to a consensus. Time, that (I must say unfortunately) is not there anymore since every one wants to have the latest and greatest toy to play with at best already yesterday.
You see how fast this discussion takes us away from technical stuff we all love to do and leads us into spheres where other factors rule the world. Again, I do see your point and deep inside me I full agree with you. I just do not see it happening in the current scenario we have around.
Let's get back to your approach:
set of predefined, blob related questions (to be discussed) should be answered.
Let's take it literally as you want. What if the answer to the question "Would the blob ever be open sourced?" is "No!"? What would be the next action in your scenario triggered by this answer?
As Martin pointed out already, to me it sounds like "To many blobs with no open source in sight and we will reject this platform", too. But I might be wrong here simply because I internally answered the question above for me without it being answered by your approach directly. So, to be able to judge properly on the approach I miss the targeted outcome of your approach (I know that it is just a proposal to start the discussion, I just want to make my thoughts clear here). Because I don't believe that having a set of questions answered honestly by the poor guy, who currently is in charge of bringing in this particular new interface for the blob or the blob itself, will lead to a more open policy at a given vendor. And yet again, answering this kind of questions is real work! Because the poor guy mentioned above now have to have meetings with various internal actors, describe the situation to them and hope that they will be able to provide the answers. In most cases, I guess, he can repeat the asking and explaining on the next linked person a few times. I am not sure if that guy will ever get the time for this relay run, especially if the outcome is not clear or guaranteed.
So yes, we need to stay in a close conversation with the vendors and keep them in a short loop. I am just not sure if we as coreboot alone can get that managed due to the lack of a business-model the vendor would be interested in. On the other hand I feel sorry for the poor guy mentioned here. Just because we are so upset with a particular vendor (due to the past issues we all may have experienced) we should behave correct when it comes to treatment of individual contributors, especially when those are quite new to the community. So instead of barking around on Gerrit and blocking stuff from being developed let us be constructive and provide helping hands and guides on Gerrit and on IRC. If I were the guy in question and I would be welcomed in the community the like, for sure I would feel sad.
Werner
-----Original Message----- From: Nico Huber nico.h@gmx.de Sent: Sunday, November 7, 2021 1:56 PM To: coreboot@coreboot.org Subject: [coreboot] Re: Another year, another blob?
Hi again,
originally, I was hoping for a more comprehensive discussion about possible solutions for the friction created by late, undiscussed additions of blob- support code. Alas, that didn't happen, and my own proposal below was misunderstood. So I'll try now to provide some rationale.
First of all, I have to say that what I write is meant literally. Please don't try to imagine something between the lines. But if you really feel like you have to, please just ask how it was meant.
On 20.10.21 14:24, Nico Huber wrote:
a recent yet-another-blob occurrence reminded me that I wanted to write about the matter for a long time.
Every few months, it seems (if not, more often), a new blob is introduced to coreboot. Alas, this is often hidden to the last minute, creating unnecessary friction and unfortunate, set-in- stone solutions that haunt us for the years to come.
When I wrote "a new blob" I meant a new kind of blob. Not just another instance of a known blob with the same interface as an existing one, but rather something new that needs its own support code in coreboot.
My proposal: How about we set up some guidelines how to proceed when adding
support
for a new platform that requires any blobs?
IMO, such guidelines could help the developers who are tasked to add blob- support code. If we had a documented procedure, they would know what to do and could justify towards their employer, if necessary, that they need to do more than just pushing the code.
My vague idea is as follows: Before the very first commit for such a new platform can be merged, a
In my experience people often see such matters as rather unpleasant, so they tend to defer the discussion. They might even maneuver themselves into a corner because they are too afraid to bring it up. Having a clear rule when it should happen would preempt such a situation. When some- thing is unpleasant but necessary, it's better to be done with it, isn't it?
set of predefined, blob related questions (to be discussed) should be answered.
Beside exceptional bad-blob situations (see below), answering such questions should be enough to move forward, no matter the answer! We want people to be honest with their answers, hence we mustn't judge them for something their employer committed. (I thought that is obvious).
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.
This was my attempt to be clear about the scope. If we avoid to forget something from the beginning, we lower the risk to run into awkward situations later.
IMO, just answering all questions shouldn't suffice to unlock the merge. If there's some downside that definitely outweighs the benefit of adding the new platform, it should be blocked until the blob situation can change. For instance, we had in the past blobs that needed to be cus- tomized under NDA per board. Something like that doesn't seem to be useful for a free-software project.
Maybe this was a bad example. Anyway, I thought I was just stating the obvious: There are limits. For instance, even if we set up a procedure like the questions proposed, that should not allow to bring blob-support in that we wouldn't allow without such a procedure.
The whole proposal was meant to ease bringing code in that we can bring in. And if something was so bad that we really couldn't, it would allow us to realize that early enough before people wasted a lot of time. I see people suffering that are tasked to bring in new blob support. I want to help them. I think we could help them this way. Having some unpleasant questions answered would just be a nice side effect. ;)
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Werner,
On 08.11.21 12:24, Zeh, Werner wrote:
I fully can understand your point of view in this discussion. Unfortunately, we do live in a real world with real companies that are business-driven. With this sidenote in context the world changes dramatically in this regard.
Your request for an early discussion whether this or that decision is acceptable pretends that a silicon vendor is willing to start this discussion fully open at a time where he by himself is not yet clear how the feature in question will finally look like (because once the vendor exactly know how it will look like it is set in stone [or silicon] already). Given this, communication on topics like this is very restricted, even inside a company. Everybody of us has experienced already that teams inside of a big company working on the same project but just on a different facet of it are often not aware of what is going on at the neighbors. Why is that? Well, this is IMHO because in our world more and more work is spread among viewer people. I do not see that this is evil-driven, it is just the lack of time the individuals have to get their job done in a fixed "24-hour-per-day-world". So I guess even if the companies would be willing to follow your approach to discuss things early we still will not get a perfect world. And discussing things implies that it will take some time to get to a consensus. Time, that (I must say unfortunately) is not there anymore since every one wants to have the latest and greatest toy to play with at best already yesterday.
well, it's not true for the PSE. It may be true in other cases, hence I agree with you. And that's why my proposal was to have "predefined" questions so there is no need to have a discussion before the work on Gerrit can continue. The answers could certainly ignite a discussion, but that shouldn't stall anything.
You see how fast this discussion takes us away from technical stuff we all love to do and leads us into spheres where other factors rule the world. Again, I do see your point and deep inside me I full agree with you. I just do not see it happening in the current scenario we have around.
Sorry, it seems you misunderstood my proposal. In any case, please help to find a better solution if you think mine doesn't work.
Let's get back to your approach:
set of predefined, blob related questions (to be discussed) should be answered.
Let's take it literally as you want. What if the answer to the question "Would the blob ever be open sourced?" is "No!"? What would be the next action in your scenario triggered by this answer?
Merge the answers into our repo. I think it's valuable to have them under Documentation/.
As Martin pointed out already, to me it sounds like "To many blobs with no open source in sight and we will reject this platform", too. But I might be wrong here simply because I internally answered the question above for me without it being answered by your approach directly. So, to be able to judge properly on the approach I miss the targeted outcome of your approach (I know that it is just a proposal to start the discussion, I just want to make my thoughts clear here). Because I don't believe that having a set of questions answered honestly by the poor guy, who currently is in charge of bringing in this particular new interface for the blob or the blob itself, will lead to a more open policy at a given vendor.
I don't think that it will change anything at a vendor either. And that was never the point. I want to make working together at coreboot.org better.
In this regard, nothing needs to change at the vendor (would help a lot of course but it's not a hard requirement). The problems that led to stalling the PSE patch for instance are all on our side. We did not talk about it early enough, so now nobody knows what exactly is going on and whom to trust. That mentioned MMU for instance that would mitigate the concerns brought up in the leadership meeting, AIUI. If we'd have looked into that half a year ago, we wouldn't have to wait for it now and do everything in a hurry.
And yet again, answering this kind of questions is real work! Because the poor guy mentioned above now have to have meetings with various internal actors, describe the situation to them and hope that they will be able to provide the answers. In most cases, I guess, he can repeat the asking and explaining on the next linked person a few times. I am not sure if that guy will ever get the time for this relay run, especially if the outcome is not clear or guaranteed.
That depends on the set of questions and expected answers. We haven't even started to discuss them ;)
For instance, when asked if a silicon vendor would like to work with the coreboot community on a different solution. If the answer is not a clear "no", it could just be "not right now". Nobody said anything yet about the expected quality of the answers.
So yes, we need to stay in a close conversation with the vendors and keep them in a short loop. I am just not sure if we as coreboot alone can get that managed due to the lack of a business-model the vendor would be interested in.
Are you just repeating what people told you? I've heard that a lot. And also heard the opposite. Intel for instance clearly wants things upstream for their own profit. They know it's valuable.
On the other hand I feel sorry for the poor guy mentioned here. Just because we are so upset with a particular vendor (due to the past issues we all may have experienced) we should behave correct when it comes to treatment of individual contributors, especially when those are quite new to the community. So instead of barking around on Gerrit and blocking stuff from being developed let us be constructive and provide helping hands and guides on Gerrit and on IRC. If I were the guy in question and I would be welcomed in the community the like, for sure I would feel sad.
Right. That's what we need to change.
Nico
-
Andy Pont -
Martin Roth -
Matt DeVillier -
Nico Huber -
Patrick Georgi -
Paul Menzel -
ron minnich -
Zeh, Werner