I feel like this discussion is getting slightly out of hand, so let's try to regroup a bit and move the discussion back to the original topic : how to handle the FSP headers in coreboot. I fully understand and agree with Nico's frustration about the blobs situation and I think that's a bigger conversation than needed right now. I do encourage discussing it and finding a good solution to avoid having a similar mess in the future (or now, but in a different thread to avoid going off-topic). I think Nico's idea of setting up rules for how/what to merge in the future is a good idea and needs to be further discussed until everyone is happy with the rules defined.
I would personally say "if the FSP headers in coreboot are for FSP 2.5.0 which is newer, then why isn't that 2.5.0 file made public?". If we were to have a rule, then maybe forcing blobs to be available publicly before having coreboot use/integrate them is a good step, so if you plan on pushing a commit that adds FSP 3.0 to coreboot, then that commit won't be merged until the associated blob becomes publicly available (even if it's on intel's github and is non redistributable), because merging commits that adds headers/support for some blob that nobody has access to makes no sense if we think of coreboot as a project that any enthusiast can clone and build for any machine if they want to.
Now, back to the discussion about the "incompatible FSP headers", here are the possibilities : - should we merge my patch that makes the FSP header compatible with the public blob, and let the CrOs coreboot clone have its own commit that reverts it, - or abandon my patch (which means I can never send a working board-status for the librems without having a dirty tree or a version commit hash that doesn't match upstream) - or have the possibility to choose between the two (either via #ifdefs or via a variants method). - or, if Intel people are reading this right now (or someone here can poke them directly), have the public release updated so this matter can be dropped entirely (the public update would need to be released *very* soon though).
Should we put this to a vote now, or should we discuss the possibilities/alternatives some more, if anyone has ideas on how to tackle this specific issue ?
Thanks, Youness.
On Thu, May 10, 2018 at 9:34 PM, Nico Huber nico.h@gmx.de wrote:
On 11.05.2018 01:39, Timothy Pearson wrote:
Not to jump too far into the fray, but couldn't this be handled by simply not blocking coreboot development on proprietary blobs? For instance, if someone wants to implement a feature that requires repository-wide changes (e.g. the timestamp stuff that went in a couple of years back) that happens to break only some blobby boards, that the feature should be implemented anyway and the broken blobby boards added back in as the vendor has time / inclination to fix?
If we maintain the code for end users and not for vendors, vendors won't do anything. And the end users can't, I would call them developers otherwise.
Basically, this seems to be what Linux already does for kernel work. The benefit of upstreaming open code is that other people will maintain it for you, but if you really need to publish a binary only driver (NVIDIA) then you have the full burden of maintenance on yourself as the vendor. This encourages contribution back without putting an arbitrary administrative limit on what kind of blob level is acceptable.
The difference here is that Linux made it. It's not only accepted by vendors but actively employed. I fear for coreboot, currently, it's mostly the silicon vendor's customers that want (or maybe even only accept) it. Plus coreboot is firmware, nobody is used to maintain firm- ware.
IMHO, we should make coreboot most easy to port to the widest range of boards possible. To extend the community. If that's only feasible through blobs (atm?), I can take it. But if a blob only helps that one company who built it, I don't see much value in it.
Nico
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot