Am Di., 17. Nov. 2020 um 18:54 Uhr schrieb Peter Stuge peter@stuge.se:
Patrick Georgi via coreboot wrote:
coreboot doesn't, cbfstool does.
If that were the case things would already be a lot better!
Alas, coreboot unconditionally requires vboot in these files:
Oops, I forgot about those, you're right!
So: we discussed that in today's meeting and had two take-aways:
1. people have issues with older host toolchains failing to build vboot. We'll work on improving those scenarios.
2. We generally prefer to build our utilities fully featured to prevent partial feature sets from popping up in installed binaries. That said, if there were a patch that cleanly cuts out cbfs hashing support from coreboot (and cbfstool used for building coreboot) based on a Kconfig flag, we would consider it.
"Cleanly" meaning: - It needs to be optional - The result needs to be maintainable. Things shouldn't break apart when looking at the flag funny - cbfstool should behave properly and reasonably when built without hashing but the relevant options are used (that is: say that it's a stripped down build, not just "command line error") - cbfstool and cbfs in coreboot without those flags still need to be able to deal with hash attributes sanely, that is, skip them safely. I don't expect that to be an issue (the data structures are robust enough), but something to keep in mind.
Maybe we view Kconfig differently. I expect it to control not only the
final build artefact but also the build process, meaning what gets built and what is needed for successful build.
I'm not entirely happy about the way we use Kconfig to enable ccache (to pick an example) because IMHO changes to config.h should lead to a different coreboot build (outside config.h). I guess with this "feature", the build would be different, so this satisfies my personal criterion.
Right, but maybe we at least agree that requiring some submodule(s) for nothing is at a minimum unneccessary?
As I mentioned elsewhere, we could import vboot as a git subtree (even though I wouldn't recommend it). That changes next-to-nothing for users (but makes life hell for developers), but satisfies that criterion. So, why the hate on submodules?
I don't want any submodules, so I go over the source and remove the
requirement.
I lined out how that could look like above. (Good) Patches accepted.
Patrick