On 1/5/23 12:31, Gerd Hoffmann wrote: > On Thu, Jan 05, 2023 at 03:21:05PM +0800, Min Xu wrote: >> From: Min M Xu <min.m...@intel.com> >> >> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4236 >> >> Similarly to the "cadence" mentioned in commit d272449 ("OvmfPkg: >> raise DXEFV size to 11 MB", 2018-05-29), it's been ~1.75 years since >> commit 5e75c4d ("OvmfPkg: raise DXEFV size to 12 MB", 2020-03-11), >> and we've outgrown DXEFV again (with NOOPT builds). Increase the DXEFV >> size of IntelTdxX64 to 13MB now. > > Not sure this makes sense given that you want split DXEFV into two > smaller volumes for IntelTdx (patch series sent in december IIRC). > > Also we maybe should move the MEMFD section to a Include/Fdf snippet > to reduce code duplication and make it easier to keep things in sync?
sigh, I followed up on this, but mistakenly, I only sent it to Gerd. Reposting to the list as well: ... the only comment I have here is for this lasst paragraph. The problem with centralized code is the same as the advantage of centralized code. You modify it once and it affects everything. But for example I cannot *test* everything. Code duplication in edk2 has helped in the past with separating responsibilities. One example has been Xen. Originally, in OvmfPkg, Xen support was integrated into a bunch of other modules, and there was no dedicated Xen platform. When Xen got introduced to ArmVirtPkg, it got its own dedicated platform, and it showed us how much easier maintenance would be that way. Xen-based developers and QEMU/KVM-based developers virtually never cross-tested (nobody has the "other" setup, or the time to test it). So Xen-oriented patches in OvmfPkg kept breaking QEMU/KVM functionality, and of course vice versa; whereas in ArmVirtPkg, no such cross-interference was seen. After a while we separated Xen to a new platform under OvmfPkg too (TianoCore#1689, TianoCore#2122), and there was much consequent rejoicing. Jordan slightly disagreed with the split, and I agreed with him from a purity sense, but from a practical maintenance POV, the joint Xen<->QEMU/KVM codebase had been a nightmare. This was one of my main driving principles during the initial discussions about TDX. I think extracting further commonalities between the TDX platform(s) and the traditional platforms works against that. It creates an area where modifications must be tested at the same (for the same patches) by multiple disparate teams. I know I couldn't do that. Cloning BZs and posting ported patches helps. At the same time: if regular maintainers *can* and *are willing* to test such central changes in *all* affected platforms, then yes, centralization is absolutely vital, because then it *saves* work. So I guess it must reflect the community's structure. Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#98024): https://edk2.groups.io/g/devel/message/98024 Mute This Topic: https://groups.io/mt/96068199/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-