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