Am Mittwoch, 15. Dezember 2010, um 20:17:18 schrieb Xavi Drudis Ferran:
If the later I don't like the idea and at least I would like a huge warning "BLOBS IN HERE !!!" at the end of the make output.
I avoid the term "blob" for two reasons: 1. "BLOBS" (in this context) is an FSF scare term. Free and Open Source software had to endure FUD long enough, we should know better than to participate in that. 2. "blob", as used by the FSF, is not cleanly defined, and their use of that word or its predecessors changed over the years. It used to be that their main issue was with binary components that are run by the CPU, but now it encompasses much more.
I prefer the OpenBSD definition of "blob": binary components that run on the CPU. That a clear line drawn in the sand, and a useful distinction, too. Unfortunately GNU/blob spoiled that.
<rant> Applying the current FSF use of the word, a graphic rendered to png or jpeg without the source material (vector graphic, gimp image with multiple layers, ...) shipped with it is a blob. We're lucky that we never added a default bootsplash image to the tree!
I had to debate with GNU developers if the S-Boxes in AES are "blobs", and if there's a "preferred format" for them (ie. if they could be calculated). They can't be calculated (there are a couple of formulas to verify if an S-Box is valid, but many are), but if you pick the wrong "valid" one, you get a different (and probably less safe) algorithm. The FSF meaning of the term only scares the same people who use it that way. </rant>
That there aren't any binary components in the tree is simply for the fact that they're not redistributable: We usually scrap them from vendor BIOSes, and they're not separately available. That won't change. (It would spark quite a debate when storing binaries in the tree would actually be proposed, but we never even got that far for the stated reason)
The other fact: Hardware relies more and more on update-able components in flash, without any knowledge of what this is. Maybe it's 8051 code, maybe it's VHDL stuff of some sorts, maybe a table like the S-Boxes, or a JPEG image. There is no preferred format, there's usually no disassembler for the data, or documentation that can be read outside the high security area at the vendor (and very likely only in 5pt print, orange glyphs on red paper in the area, to prevent anyone from making copies), but there's a single invariant for most of them: Without the data around, your system won't boot - it's useless as a brick, with the only feature that it sucks power.
For this reason, I'm thinking about adding a "thirdparty" directory, which contains only a script. That script contains a list of hash values and "real file names", and renames files within that directory which match a hash to the assigned filename. The script would be a tool to simplify handling for users who have to scrape their binary parts from BIOS images: Fetch the data, put it in the directory, run the script. If the data is known, it's automatically available for the board or chipset that needs it.
If you prefer to live without the file, simply don't put it in there. Your board might be less useful than a brick, but that's your choice. The default will be to not ship those files, both because we aren't allowed to redistribute them, and to have a safe default from a license perspective. It's also a safe default from an operation perspective, as the build will break by default (we might have to tweak the buildbot a bit to be tolerant of that, for example by seeding the thirdparty directory on the buildbot with empty files of the right names and sizes)
This patch won't change anything in this regard. The plan with the script I outlined is only where I see where this project is heading, for technical reasons. What this patch does is eliminating a bottleneck: Right now we have to maintain a list of files that can be added to the CBFS image at a central location, and that won't scale in the future. Nothing more, nothing less. No feature at coreboot runtime (or misfeature as you'd probably see it) is added or dropped, it's just build system magic.
Patrick