On Jan 31, 2013, at 2:01 PM, "David F." <[email protected]> wrote:
> Andrew, Thanks. I think I get it, another way to say it would be the PCD
> replaces the #ifdef and #defines, replacing #if with compile time conditional
> builds (though compiler optimizations) that prevent code rot and #defines
> (and perhaps static const int var= which in c++ or other compilers may be
> treated as #defines) with memory space that is patchable in binaries? And
> the 1-4 view is how you define those variables to use.
>
> Also, notice most things reference C - I presume one could get C++ code
> (without exception handling) to work okay (change new/delete to malloc/free)
> similar to how I set it up so I can code the Windows DDK using C++?
>
Well back to that history of paranoia... We don't include any outside libs,
even the ones needed to make the compilers work. We don't have C++ support,
since C++ in the hands of a novice programmer is a dangerous weapon. But folks
have discussed in the past about getting an embedded subset of C++ working, so
I'm sure it is possible.
I think you may find the C++ compiler may generate calls to intrinsics that you
may have to provide. We have generally avoid providing these functions for C to
make it easier to port new compilers (so no initing structures with = or doing
64-bit math without lib functions) but we hit the breaking point when we ported
to ARM. It seems some ARM processor don't have a divide instruction, so we
ended up adding a compiler intrinsic lib for ARM that supports RVCT and GCC.
You can do something similar. You can use the NULL library class to force a
library to link with your modules. The following example is the ARM compiler
intrinsic lib statement that ends up in DSC files:
[LibraryClasses.ARM]
NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
Also since we don't use any system include files you have to make sure that
what every basic C++ header files you use make sense for this environment.
Thanks,
Andrew
> Thanks again.
>
>
>
> On Thu, Jan 31, 2013 at 1:21 PM, Andrew Fish <[email protected]> wrote:
>
> On Jan 31, 2013, at 12:05 PM, "David F." <[email protected]> wrote:
>
>> Thanks Mike. That leads me to the next point of confusion. Is the purpose
>> of the Platform Configuration Database (PCD) to share variables across
>> drivers, applications, and/or whatever is launching an app or driver; or is
>> it just a method the build system offers for you to define variables in a
>> configuration file instead of a .h header file?
>>
>
>
> There were a couple of requirements for the edk2 that ended up turning into
> PCD.
> 1) Config knobs for a driver need to be configurable by the platform so that
> they could be setup options (Hii), or constants, or SKU defined, programmed
> in the factory (VPD), etc.
> 2) We needed a mechanism to support patching config values into a binary, and
> a runtime mechanism to configure a binary module.
>
> Both Mike and I hated code bases with large numbers of #ifdefs to turn stuff
> on and off because in our experience code will rot out in some of the #ifdef
> paths and make the entire thing very hard to maintain.
> It was also the vision that chip vendors would provide a package(s) of code
> to the platform vendor. If a chip vendor had a large number of config knobs
> for validation or just end customer configuration we wanted the person
> building the platform to be able to set the config knobs to what made sense
> to that platform. We also wanted to minimize the changes that the platform
> vendor would have to make to the chip vendors code, so syncing up with future
> code drops would be easier.
>
> I'm sorry that the terminology for PCD can get confusing and I think its
> partly my fault. Here is my 10,000 foot view cheat sheet for how to
> use/conceptualize PCD:
> 1) .DEC file - is the definition of the PCD entry. You get the pick the legal
> forms, and default values for a PCD. When in doubt make it as flexible as
> possible [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic,
> PcdsDynamicEx].
> 2) .INF file - The PCD settings in the INF represent how the module was
> coded. When in doubt use the generic form [Pcd] with PcdGet32() , and
> [FeaturePcd] with FeaturePcdGet().
> 3) .DSC file - Within the constraints of how the PCD was defined and used in
> modules you get to pick the form of the PCD for this specific build and set
> values.
> 4) Ex - The Ex versions of the APIs include the GUID. These are only needed
> for binaries or modules not built together. Each build will generate a unique
> token space that the code uses, and this is to save space.
>
> There are some other advantages to PCDs over h files. Since in any given
> build a library is only built one time you can use FixedAtBuild PCD values to
> have different settings on a per module basis for the library. So for example
> you can pick a single driver to have very verbose DEBUG macro output while
> the reset of the system is less verbose.
>
> Thanks,
>
> Andrew Fish
>
> PS. Our dislike of lots of #ifdefs is why we ended up with FeaturePcdGet().
> This lets you have an #ifdefs like construct where both sides always compile
> so code never rots out. As long as you compiler does a good job dead
> stripping you don't pay a size penalty in the binary.
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan_______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
