Hi all, On 12.11.20 03:29, Julius Werner wrote: > I don't think it's fair to single in on vboot as the big problem here.
it's not by any definition but, FWIW, it became one in practice. I don't think it's because of GCC versions or anything that we should try to fix by testing. One big difference to other build-time dependencies (i.e. what we pull in via buildgcc) is that vboot is not (as much) focused on portability. Julius also mentioned elsewhere that the same issues that can sneak into vboot can hit us anywhere else. That's generally true but, IMHO, highly unlikely. When we work on central parts of the build process (e.g. cbfs- tool) and review patches there, we take care of portability and keep it to standard C, FWIW. (I know people like to use packed structs, but that's not too funky, I guess.) There's another issue, once one tries to fix a problem. If it occurred somewhere in our tree, it can be fixed within the hour. But if it's ex- ternal, it needs to be upstreamed there first, then a complete new state of the external software needs to be tested and pass Jenkins and then the submodule pointer can be updated. I never tried but a random guess: for vboot it takes a month on average maybe? That's not on vboot, I know it's a general submodule issue. Just some thoughts... Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
