> On Feb 17, 2022, at 4:26 PM, Oram, Isaac W <[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]> 
>> 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]>
>>> Sent: Wednesday, February 16, 2022 7:26 PM
>>> To: Kinney, Michael D <[email protected]>
>>> Cc: [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]> 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] <[email protected]> On Behalf Of 
>>>>> Andrew Fish via groups.io
>>>>> Sent: Wednesday, February 16, 2022 1:02 PM
>>>>> To: edk2-devel-groups-io <[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 (#86739): https://edk2.groups.io/g/devel/message/86739
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