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/+/f836ff362b0411ab6c9e580b1e32760aa6ea7e31/README.md
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
