On 11.05.2018 01:31, Julius Werner wrote:
Ok, I'll try to break this loop here. You are repeating the great bene- fits for a user (that I agree to) even if a blob is involved. And I keep asking why it should happen on our master branch (I don't see how we would take something away by not maintaining everything. Also, I never tried to exclude all blobs). It seems somehow we talk past each other.
Why should it not be on our master branch? What is your exclusion criteria? To my knowledge the only reason why we ever remove boards from the master branch is because they become a maintenance burden when it's hard to make them fit into new/changing APIs and there's no developer volunteering to keep testing for that board. And in those cases, whether that burden is related to a blob or not, I totally agree that we can consider removing them from master. But I don't see how that has anything to do with whether a blob is mainboard-specific or not. If a board with those blobs is still easy to pull along with the changes we want to make on master and there's someone willing to regularly test it and keep it healthy, I see no reason for exclusion.
Well, every added platform and board increases the maintenance burden. And we can't maintain everything. I'm just very biased towards keeping things that are easier to port to new boards, to spread coreboot. And what I called "shit", i.e. not board-agnostic blobs, obviously isn't easy to port to new boards.
On the other side, the general benefits of keeping stuff in master are obvious -- users of that board can benefit from the continued development of coreboot core features. For example, if you have a 3 year old Chromebook like Veyron_Jerry today then the firmware Google ships you is still frozen on a three year old branch, but since it's alive and healthy in coreboot master you can build your own image from there and automatically get cool new features like the persistent CBMEM console. Ideally, it would be best if we could keep everything in master forever... we just decide to drop stuff as a trade-off if it actively prevents us from making forward progress on other boards, but that decision is not directly related to the presence or absence of blobs.
What if something "passively" prevents us from making progress? It's hard to measure how much more work patching and reviewing is because of additional platforms. Alas, I can only speak for Intel platforms, because that's what I work most with. Maybe everywhere else blobs look better, then I'd probably need to apologize to the makers of greater blobs. But here is what I experienced in the last year: The time I spent on fixing bugs that crossed FSP platforms was about 500% of the time I usually spent for comparable things. Mostly because something interacted with the undocumented blob in an implicit way (eg. you see things happen in a specific order and don't know why or if it matters). So I couldn't just fix things without a deeper investigation (asking very unresponsive persons, often falling back on Aaron as a last resort). So, yeah, it might just be the code surrounding FSP, but at least there it's an incredibly increased maintenance burden. Oh, forgot to mention, I also hit about three times as many bugs as usual (both inside and outside of the blob).
Anyway, lamented enough again. There are better targets to remove to decrease maintenance costs (e.g. whole platforms that are only used by reference boards and are kept for political reasons only). If some board is actively used and that's visible to us, I agree, we shouldn't remove it (although, I still have strong feelings about platforms where users have to carve the binary out somewhere because we can't provide it; nor even a pointer to it).
Nico
-
Nico Huber