On Tue, Nov 30, 2021 at 6:54 AM Ivan Ivanov <qmaster...@gmail.com> wrote: > > Personally I don't see any reason for branching, if 99% of the rest of > coreboot code (payloads etc.) is compatible. This will only get us > outdated for these components on this branch, which otherwise could > (and should) be kept simultaneously up-to-date to get the latest > goodies. So, just make two folders: 1 - resource allocator v3, 2 - > resource allocator v4, and access either v3 or v4 from outside > depending on your board selection.
This can work, however it depends on how much other code is impacted. A good example of this is the new SMM module loader introduced recently to accommodate CPUs with >32 threads (CB:43684). It was merged with "v2" in the filename so that work could continue on newer server CPUs while the original loader was still in use everywhere else. After some time spent testing it, the "v2" module loader became the default and "v2" was dropped from the name (CB:51528). In that case the code was isolated and the newer version was essentially a drop-in replacement. But even then, there was at least one known case where something broke (CB:52765). For something like the resource allocator I would expect a lot more dependencies on other parts of the tree. This can turn into a big and difficult-to-debug mess if code beyond the resource allocator has different behaviors depending on which version is being used. tl;dr: What you suggest is possible, but cost and benefit need to be considered and the cost can be very high if other parts of the codebase are impacted. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
