Re: [edk2-devel] [PATCH] OvmfPkg/PvScsiDxe: Fix VS2019 build error because of implicit cast

["Laszlo Ersek" <lersek@redhat.com>]

On 04/01/20 00:17, Liran Alon wrote:

> I would also mention that there are some bizzare code in EDK2 that
> defines it's own ASSERT() macro that just does CpuDeadLoop(). E.g.
> ArmVirtPkg/Library/ArmVirtDxeHobLib/HobLib.c

This is a very special case.

Please see the justification in commit ad90df8ac018
("ArmPlatformPkg/ArmVirtualizationPkg: Add private HobLib implementation
for DXE phase", 2014-09-18).

The stock HobLib instance depends on DebugLib, for using the normal
ASSERT() macro.

Furthermore, the stock serial-based DebugLib instance depends on
SerialPortLib, for printing messages.

That produces a HobLib -> DebugLib -> SerialPortLib dependency chain.

But, in case of this particular platform, our SerialPortLib instance
depends on HobLib, for retrieving the particulars of the serial port.
This creates a dependency cycle:

  HobLib -> DebugLib -> SerialPortLib -> HobLib

which makes the platform un-buildable.

We had to break the dependency cycle somewhere, and the best (or maybe
only -- I don't recall exactly anymore) link to break was the HobLib ->
DebugLib dependency. We introduced our own HobLib instance, which (IIRC)
was almost identical to the stock one, except that its (only) DebugLib
dependency, namely the ASSERT(), was reimplemented with a plain
CpuDeadLoop(). And so the dependency chain ended up as:

  DebugLib -> SerialPortLib -> HobLib

Not circular any more.

> and OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c)

Very similar same case; here we even have a comment:

//
// We can't use DebugLib due to a constructor dependency cycle between DebugLib
// and ourselves.
//

The BaseDebugLibSerialPort instance depends on SerialPortLib, so a
SerialPortLib instance cannot "depend back" on DebugLib, in combination
with BaseDebugLibSerialPort.

Thanks,
Laszlo