Good thing about what I've suggested - "different places for v3 and v4 allocators" - is that it's (almost?) already done ;-)
вт, 30 нояб. 2021 г. в 20:12, David Hendricks <david.hendri...@gmail.com>: > > 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
