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]
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

Reply via email to