> On Feb 17, 2022, at 5:36 PM, Michael D Kinney <[email protected]> 
> wrote:
> 
> Hi Andrew,
>  
> I forgot about the library constraints.
>  
> Unless we want to first add a feature to build a library instance for each 
> module type into
> a different build output directory, we cannot support setting a FixedAtBuild 
> PCD for each
> module type.
>  

Mike,

Yea I’m thinking this is a good reason to maybe not add more knobs. 

I was trying to get tricky and have code conditionally use a global so I could 
use the lib XIP when I shot myself in the foot. 

Thanks,

Andrew Fish

> If you use PatchableInModule, you can post process all the modules to set 
> individual
> module PCD values.  You have to do two steps.  One DSC to build all the 
> modules and
> generate AsBuiltInf.  2nd DSC/FDF that references the AsBuildInfs and sets 
> the 
> PatchableInModule PCD values in the scope of the modules needed.
>  
> The only reason the different ARCHs for PEI and DXE works is because the libs
> for each ARCH are build separately and already have different build output 
> locations.
>  
> Mike
>  
>  
>  
> From: Andrew Fish <[email protected] <mailto:[email protected]>> 
> Sent: Thursday, February 17, 2022 4:42 PM
> To: [email protected] <mailto:[email protected]>; Oram, Isaac W 
> <[email protected] <mailto:[email protected]>>
> Cc: Kinney, Michael D <[email protected] 
> <mailto:[email protected]>>
> Subject: Re: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different 
> values for PEI and DXE?
>  
>  
> 
> 
> On Feb 17, 2022, at 4:26 PM, Oram, Isaac W <[email protected] 
> <mailto:[email protected]>> wrote:
>  
> Andrew,
> 
> It is a reasonable ask, but I lean towards voting no.  We can more or less do 
> the equivalent by breaking a monolithic build into a set of phase specific 
> build/DSC/FDF or something similar.  That seems more flexible anyway.  Maybe 
> we want binaries with settings based on maturity more than phase.  And so on.
> 
> 
> My primary concern that the complexity added to an already complex feature.  
> PCD have a lot of binary compatibility challenges anyway.  And this doesn't 
> add any that don't already exist, but it does make it a lot easier to 
> introduce a mismatch issue.
> 
>  
> I shot my self in the foot with the Fixed* macro in a library so I did not 
> get the drivers override. So I feel that pain. You need to used the non Fixed 
> form from a lib to get the value from the global produced by the driver. 
> 
> 
> 
> My more recreational question is if this makes sense in most cases, or if 
> there are a limited set of PCD that it makes sense for.  A lot of similar PCD 
> are much more like shared constants and thus it doesn't make a lot of sense 
> for them to vary across executables.  E.G. drivers are asking for problems if 
> they change max string lengths inconsistently. There are definitely more than 
> one PCD where it seems reasonable.  Maybe they are the "wrong" type though.  
> Maybe they should be a dynamic type if a flexible usage is desired.
> 
>  
> I was trying to have different settings for 
> gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask is regards to the action taken 
> on an ASSERT. 
>  
> To be honest it was not my 1st choice and I was working around some early 
> boot exception handling code not saving the EFI_SYSTEM_CONTEXT and blocking 
> the scheme I was trying to use. 
> 
> 
> 
> Tangentially related, there was some previous work to make macros for phase 
> architectures.
> 
> [Defines]
>  PEI_ARCH                            = IA32
>  DXE_ARCH                            = X64
> 
> Enabling [Components.$(PEI_ARCH)] and [Components.$(DXE_ARCH)]
> 
>  
> In my case PEI_ARCH == DXE_ARCH so this kind of trick is not helpful. The 
> reality is this trick only works for non virtualized X64 platforms and the 
> edk2 supports a lot more flavors of platforms than X64. 
>  
> Thanks,
>  
> Andrew Fish
> 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=2308 
> <https://bugzilla.tianocore.org/show_bug.cgi?id=2308>
> 
> If we do something with PCD, we should probably try to be consistent with 
> this and maybe extend it or integrate it into DSC syntax.  With standalone 
> MM, it probably makes more sense to have PEI, DXE, and SMM.  RT would also 
> make sense to have different settings.  I have mixed feelings about BDS.  I 
> think it makes sense to see it as a potentially independent phase that isn't 
> currently.  But also probably won't ever be independent from DXE.
> 
> Regards,
> Isaac
> 
> 
> -----Original Message-----
> From: [email protected] <mailto:[email protected]> 
> <[email protected] <mailto:[email protected]>> On Behalf Of Andrew Fish 
> via groups.io <http://groups.io/>
> Sent: Thursday, February 17, 2022 12:22 PM
> To: Kinney, Michael D <[email protected] 
> <mailto:[email protected]>>
> Cc: [email protected] <mailto:[email protected]>
> Subject: Re: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different 
> values for PEI and DXE?
> 
> 
> 
> 
> On Feb 17, 2022, at 10:52 AM, Kinney, Michael D <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> I agree that your approach is the only way right now.
> 
> Do you have a feature request???
> 
> Well it does seem like a reasonable thing to be able to do? What do other 
> people think?
> 
> I was able to refactor my code and I did not actually end up needing to 
> override every PEIM and the PEI Core.
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> 
> Mike
> 
> 
> -----Original Message-----
> From: Andrew Fish <[email protected] <mailto:[email protected]>>
> Sent: Wednesday, February 16, 2022 7:26 PM
> To: Kinney, Michael D <[email protected] 
> <mailto:[email protected]>>
> Cc: [email protected] <mailto:[email protected]>
> Subject: Re: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different 
> values for PEI and DXE?
> 
> 
> 
> 
> On Feb 16, 2022, at 2:10 PM, Kinney, Michael D <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> Hi Andrew,
> 
> Current DSC syntax for platform scoped [PcdsXXX] sections only 
> supports CPU Arch and SKUID.
> 
> So there is no mechanism today to specify different PCD values based 
> on module type.
> 
> You can manage this in the DSC file, but it does require the module 
> scoped <PcdXXX> section for each module INF that requires a 
> different value that the platform scoped [PcdXXX] section.
> 
> 
> Mike,
> 
> That is what I ended up doing, but it required overriding every PEIM and PEI 
> Core. Seemed kind of excessive.
> 
> I think people cheat and use IA32 vs X64 to mean PEI vs. DXE on X64 platforms.
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> Mike
> 
> 
> -----Original Message-----
> From: [email protected] <mailto:[email protected]> 
> <[email protected] <mailto:[email protected]>> On Behalf Of 
> Andrew Fish via groups.io <http://groups.io/>
> Sent: Wednesday, February 16, 2022 1:02 PM
> To: edk2-devel-groups-io <[email protected] <mailto:[email protected]>>
> Subject: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different 
> values for PEI and DXE?
> 
> I’m trying to have a different platform policy for 
> PcdDebugPropertyMask in PEI and DXE. I can’t figure out how to do without 
> overriding every PEIM that I build?
> 
> My PEI and DXE has the same arch so I can’t use the CPU Arch to tell them 
> apart.
> 
> Is there something I’m missing?
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> 
>  
>  
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86749): https://edk2.groups.io/g/devel/message/86749
Mute This Topic: https://groups.io/mt/89195478/21656
Group Owner: [email protected]
Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to