Re: [edk2-devel] [PATCH 1/2] OvmfPkg: Introduce NULL class library to inhibit driver load

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

On 08/16/22 23:08, Brian J. Johnson wrote:
> On 8/16/22 07:30, Laszlo Ersek wrote:

>> On physical machines, I've seen firmware options for disabling the IP
>> stack entirely; I wonder how those firmwares do it...
> 
> I don't know how any physical machine handles that particular option.
> But one approach would be to add a GUID to the depex of the module you
> want to control, and install it only when you want the module to be
> dispatched.  That's pretty straightforward, although it does result in
> "Driver %g was discovered but not loaded!!" messages from
> CoreDisplayDiscoveredNotDispatched() if sufficient debugging is enabled.

Indeed, thanks for the reminder! ArmVirtPkg and OvmfPkg uses this
pattern with several core drivers:

PlatformHasIoMmuLib:
- depex:       gEdkiiIoMmuProtocolGuid OR gIoMmuAbsentProtocolGuid
- hooked into: PciHostBridgeDxe

PlatformHasAcpiLib:
- depex:       gEdkiiPlatformHasAcpiGuid
- hooked into: AcpiTableDxe

NvVarStoreFormattedLib:
- depex:       gEdkiiNvVarStoreFormattedGuid
- hooked into: VariableRuntimeDxe

>From these, the first and third examples are not full matches, as the
depexes injected via PlatformHasIoMmuLib and NvVarStoreFormattedLib are
always supposed to be satisfied *eventually* -- the drivers that the
dependencies are injected into are always required; the dependencies
ensure some platform specific ordering requirements.

But PlatformHasAcpiLib seems like a 100% match; it *is* meant to block
AcpiTableDxe indefinitely, if the platform chooses so (dynamically).

Thanks!
Laszlo