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: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
