Mike -
One other area (brought up by a colleague): currently if a single package
contains a lot of these PCDs, they may be enabled/disabled in a .dec file by a
!if and a FeatureFlag PCDs. But in INFs that is not possible. This forces us to
create multiple INFs, one for each PCD or group of PCDs so that the feature
flag can control the build properly (via the DSC file), since !if is not
allowed in the PCD section of an INF
Tim
From: Tim Lewis [mailto:[email protected]]
Sent: Friday, August 09, 2013 1:35 PM
To: [email protected]
Subject: Re: [edk2] PCD Database Issue #3: Build-Time Pruning Makes PCDs
Disappear
Mike -
The PCD PPI and Protocol were designed to handle data that was not known to the
module handling them. In this case, the data is in completely separate packages
from the module that uses it (because we release them separately). That's why
GetNextToken() exists: to scan the PCD database at runtime for items that the
caller does not know about. Requiring a module to explicitly declare the exact
name of a PCD in order to create that PCD in the build system restricts where
the PI spec does not restrict.
PCDs have the advantage (over PPIs and Protocols) that they can be initialized
using the meta-data. A general-purpose EDK2 tool can find them and edit them,
even if they do not know the purpose of the PCDs. Currently, the user must not
only edit the PCDs, but create and/or edit an INF.
Tim
From: Kinney, Michael D [mailto:[email protected]]
Sent: Friday, August 09, 2013 1:19 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] PCD Database Issue #3: Build-Time Pruning Makes PCDs
Disappear
Tim,
What do you mean by "adds a package to the build"? The only way to add content
to a FW build is to list the additional module INF files in the DSC/FDF file.
If the module INF files are listed, then the PCD Database will include the PCDs
listed.
This may be a mismatch in the use of the PCD feature. The PCD Database is
intended to be constructed at build time based on the FW components known at
build time. It sounds like you are trying to do something more dynamic which
is what the PPI and Protocol databases are typically used for.
Thanks,
Mike
From: Tim Lewis [mailto:[email protected]]
Sent: Friday, August 09, 2013 10:10 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] PCD Database Issue #3: Build-Time Pruning Makes PCDs
Disappear
Mike -
Not a non-FW component, just another module. Consider I have a case (real life)
where I want to add PCDs from a variety of packages all with different token
numbers, but the same GUID. A driver then accesses the PCD database to find all
PCD tokens with a specified GUID (using GetNextTokeN()), not knowing exactly
which packages were included in the build. Right now, when someone adds the
package to the build (and thus, its .dec) they must also include a dummy .inf
file that references the PCD. And thus we have
yet-another-way-that-a-feature-is-added-to-EDK2.
I understand the desire to minimize flash space. But (a) this behavior is not
documented and (b) it can't be turned off either globally or selectively. We
turn one and off other flash-consuming features with feature flag PCDs, or by
removing them from the DSC/FDF. But for this one I must update a .dec and a
dummy .inf.
Some of this boils down to the lack of conditionals in INFs and the fact that
the EDK2 build system relies so heavily on INFs to generate/pull in other
features. If you accidentally put an extra GUID in your file, it is no big
deal, because optimization will remove it in most cases because it is
unreferenced using declspec(selectany) or its analog. But PCDs are global
resources, like strings or bitmaps. In fact, strings have similar issues (try
to put a string the .uni file and then access it without using the string token)
Tim
From: Kinney, Michael D [mailto:[email protected]]
Sent: Friday, August 09, 2013 9:56 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] PCD Database Issue #3: Build-Time Pruning Makes PCDs
Disappear
Tim,
Even if a PCD is only accessed at runtime, it must be access by a runtime FW
module, which means it must be listed in the INF for the runtime FW module.
What is use case in which a PCD is only accessed by a non FW component and how
would such a component access the PCD?
The PCD database takes up space in the FLASH, so the default behavior of the
build tools is to only include the PCDs that are actually accessed by the set
of modules that are included in the build.
Best regards,
Mike
From: Tim Lewis [mailto:[email protected]]
Sent: Friday, August 09, 2013 8:59 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] PCD Database Issue #3: Build-Time Pruning Makes PCDs
Disappear
Liming -
The root question is: what criteria is used to include PCDs in the PCD
database? Currently there is no way to include PCDs in the database unless each
one is listed in an INF. And there is no documentation to this effect.
In my opinion, any Dynamic, since it is possible that the PCD will be accessed
at runtime without using any PCD macros.
Tim
From: Gao, Liming [mailto:[email protected]]
Sent: Thursday, August 08, 2013 10:49 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] PCD Database Issue #3: Build-Time Pruning Makes PCDs
Disappear
Tim:
This is like a feature request on generating PCD DataBase to include
DynamicExPcd. This may need more discussion to figure out the way on which PCD
will be included. Any DynamicEx PCD defined in Package DEC file? Or those
DynamicEx PCD used in Platform DSC file?
Thanks
Liming
From: Tim Lewis [mailto:[email protected]]
Sent: Tuesday, August 06, 2013 1:45 AM
To: [email protected]<mailto:[email protected]>
Subject: [edk2] PCD Database Issue #3: Build-Time Pruning Makes PCDs Disappear
An undocumented feature of the EDK2 build system prunes PCD entries from the
PCD database if no INF refers to them. This causes problems when PCD accesses
happen purely at runtime using generated PCD token numbers (i.e. the token
number is some form of 0x2000+X) or when PCD tokens are meant to be discovered
by searching through certain GUID (i.e. using GetNextToken() with a specific
GUID returns all PCDs associated with it). Currently, in order to work around
this, every time we create this type of PCD in the project's .dec fie, we must
also add it to an .inf.
I understand the value of auto-pruning. Currently INFs do not have a way to
disable references to PCDs that are not used because of feature flags. But
there needs to be some way to turn off this undocumented behavior.
Tim
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
