On 10/23/14 19:02, Gabriel Somlo wrote: > Jordan, Laszlo: > > On Mon, Oct 06, 2014 at 11:42:53AM -0400, Gabriel L. Somlo wrote: >> So, to decide how I feel about further splitting out DxeAcpiTimerLib >> into a version which does use PCDs and another version which does not, >> I added some DEBUG statements to track every time the host bridge >> gets queried right now, and here's what I got: >> >> >> PlatformPei:MiscInitialization() >> Base:AcpiTimerLibConstructor() (PEIM) >> Dxe:AcpiTimerLibConstructor() (DXE_CORE) >> Dxe:AcpiTimerLibConstructor() (DXE_RUNTIME_DRIVER) >> Dxe:AcpiTimerLibConstructor() (DXE_DRIVER) >> Dxe:AcpiTimerLibConstructor() (DXE_RUNTIME_DRIVER) >> Dxe:AcpiTimerLibConstructor() (DXE_DRIVER) >> Dxe:AcpiTimerLibConstructor() (DXE_RUNTIME_DRIVER) >> Dxe:AcpiTimerLibConstructor() (DXE_DRIVER) >> Dxe:AcpiTimerLibConstructor() (DXE_RUNTIME_DRIVER) >> Dxe:AcpiTimerLibConstructor() (DXE_DRIVER) >> Dxe:AcpiTimerLibConstructor() (UEFI_DRIVER) >> Dxe:AcpiTimerLibConstructor() (UEFI_DRIVER) >> Dxe:AcpiTimerLibConstructor() (UEFI_DRIVER) >> Dxe:AcpiTimerLibConstructor() (UEFI_DRIVER) >> Dxe:AcpiTimerLibConstructor() (DXE_DRIVER) >> Dxe:AcpiTimerLibConstructor() (UEFI_DRIVER) >> BdsPlatform:PciInitialization() >> BdsPlatform:AcpiInitialization() >> Dxe:AcpiTimerLibConstructor() (DXE_DRIVER) > > I think I have the mechanics of PCDs figured out. > > Between the two of you, you've suggested I use the DxeAcpiTimerLib > instance from DXE_DRIVER, DXE_RUNTIME_DRIVER, UEFI_DRIVER, and > UEFI_APPLICATION. > > After some testing, it appears DXE_DRIVER and DXE_RUNTIME_DRIVER do > indeed see the dynamic PCD I set from PEI. > > UEFI_DRIVER *clearly* does not; it gets linked against > MdePkg/Library/BasePcdLibNull/PcdLib.c, which implements > LibPcdGet* with ASSERT(FALSE).
Yes, because by default we resolve the PcdLib class to the Null instance (in the DSC files) for UEFI_DRIVER. The background is that UEFI drivers are meant to be "portable" across UEFI implementations, and the PCD protocol is not a standard protocol -- it's an "edk2-only" feature. But, referring to http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10156/focus=10197 On 09/30/14 00:17, Jordan Justen wrote: > In OvmfPkg*.dsc: > * [...] > * Replace BasePcdLibNull.inf with DxePcdLib.inf as needed in DXE/UEFI > LibraryClasses. > > (This paragraph is a bit tangential. Feel free to ignore it. :) I > think this is not quite valid for pure UEFI drivers, since they should > not rely on the PCD protocol. But, I think that OVMF as a platform can > bend this rule. [...] So, we might want to decide that going forward we will indeed bend this rule, and *explicitly* declare all UEFI_DRIVERs under OvmfPkg/ non-portable outside of edk2. In which case you'd simply change the default PcdLib resolution for UEFI_DRIVER and UEFI_APPLICATION modules in the DSC files, as Jordan describes in the quote. Thanks Laszlo > > I have no idea about UEFI_APPLICATION, since it never showed up in my > tests. > > Is there an easy way to find out whether it'll work or ASSERT(FALSE) > instead ? > > If not, I'm planning on using PCDs just from DXE_[RUNTIME_]DRIVER, and > we can always switch more stages over to DxeAcpiTimerLib from Base > later, if that turns out to be possible. > > > Thanks, > --Gabriel > ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
