Re: [PATCH V1 1/1] OvmfPkg/IntelTdxX64: Raise DXEFV size to 13MB

["Gerd Hoffmann" <kraxel@redhat.com>]

> > 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?
> 
> 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.

Sure, we have to check where sharing makes sense and where not on a
case-by-case base.  Some truely generic bits (like the list of usb
drivers, or crypto/network support) might make sense to share across all
platforms.

Platform-specific bits are a different story.  They would probably be
restricted to the three kvm variants we have (i.e. OvmfPkgIa32,
OvmfPkgIa32X64, OvmfPkgX64).  Possibly AmdSev and IntelTdx too (again
depending on the kind if change).

> 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.

I think with PlatformInitLib is a nice solution for that.  It allows to
share code instead of cut+pasting stuff.  But the different platforms
still have their own setup code.  They can use all, some or none of
the helper functions from the library and we also don't have a single
code path which must detect and handle all possible cases at runtime.

take care,
  Gerd