Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/38421 )
Change subject: commonlib/bsd: Add new CBFS core implementation ......................................................................
Patch Set 6:
(1 comment)
https://review.coreboot.org/c/coreboot/+/38421/5/src/commonlib/bsd/include/c... File src/commonlib/bsd/include/commonlib/bsd/cbfs_serialized.h:
https://review.coreboot.org/c/coreboot/+/38421/5/src/commonlib/bsd/include/c... PS5, Line 7: #include <vb2_sha.h>
I like the idea of having a shared code base, but in order to use it in 3rdparty apps we might need […]
I don't think we'd want to pull all of vboot into the coreboot repository. It's a big codebase and it is intended to be usable by other firmware stacks as well. The submodule model has served us pretty well for those cases for now and I think we'd want to keep that. If you want to build a coreboot-dev header package for a certain distro, you're welcome to throw in vboot headers there if you want though.
One other thing I could do here is to #include <cbfs_glue.h> and then put an #if CBFS_ENABLE_HASHING block around both the #include and the hash attribute definition. That way if another codebase wants to use CBFS stuff without checking out the vboot sources somewhere, they can just supply a <cbfs_glue.h> with #define CBFS_ENABLE_HASHING 0 and use it like that. (It goes against my general rule of never preprocessor-guarding #includes, but in this case I can agree that it may make sense in some situations.) Would that help your use case?