On 2024-07-01 14:35, Ard Biesheuvel wrote:
Ard: would you be opposed to putting a DEBUG print and/or an ASSERT in
BaseRngLibContructor if mRndrSupported == 0?
An alternative would be to place a test and noisy warning inside
SbsaQemuPlatformDxe.
I'm not sure I follow what we are trying to fix here. RngDxe will
simply not load if BaseRngLib does not find FEAT_RNG support.
If the issue is other, existing users of RngLib that are currently
served by BaseRngTimerLib, we could make the library class resolutions
introduced here local the RngDxe driver, using
SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf {
<LibraryClasses>
RngLib|MdePkg/Library/BaseRngLib/BaseRngLib.inf
ArmTrngLib|ArmPkg/Library/ArmTrngLib/ArmTrngLib.inf
ArmMonitorLib|ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf
}
Good point.
I think Ard's example solves the original purpose (providing
EFI_RNG_PROTOCOL to linux efi stub) while not breaking any potential
usage before this point.
I'd still quite like to nudge existing users onto a more recent cpu,
with less cryptic console output. But if we do the above we can drop the
conditional part and just put a test and a message in the PlatformDxe.
(And have the commit message be clear on RngDxe being added.)
/
Leif
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119741): https://edk2.groups.io/g/devel/message/119741
Mute This Topic: https://groups.io/mt/106909459/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
