public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Andrew Fish" <afish@apple.com>
To: devel@edk2.groups.io, lersek@redhat.com
Cc: Ken_Taylor@phoenix.com
Subject: Re: [edk2-devel] PCD EX interface.
Date: Thu, 23 Jan 2020 13:08:48 -0800	[thread overview]
Message-ID: <5D2A47A2-6DCE-448B-A5BA-14BE7BBA464B@apple.com> (raw)
In-Reply-To: <f3fff8ec-f8cd-dfe6-96d7-8fe618677efa@redhat.com>


> On Jan 23, 2020, at 3:21 AM, Laszlo Ersek <lersek@redhat.com> wrote:
> 
> Hi Ken,
> 
> On 01/23/20 02:37, Ken Taylor wrote:
> 
>> If I try to get the size of a DynamicEx PCD in the context of a BIOS
>> build for which that PCD is undefined, the call locks up.  I expected
>> to just get a size of 0, since the PCD is not defined in the build
>> context of the PCD DXE service.  Is this a problem that's been fixed
>> since my BIOS source code was cut?  What can I do for older builds
>> that haven't been fixed (and probably never will)?  Do I have to just
>> accept that I'm going to get garbage or lockup if I run my shell
>> utility on some builds?  Do I have to write a DXE driver and expose a
>> protocol, just so I can know if that PCD exists and is properly
>> defined?
> 
> I think the ASSERT() that you run into is the one in
> GetExPcdTokenNumber(), file "MdeModulePkg/Universal/PCD/Dxe/Service.c":
> 
>>  MatchGuid   = ScanGuid (GuidTable, mDxeGuidTableSize, Guid);
>>  //
>>  // We need to ASSERT here. If GUID can't be found in GuidTable, this is a
>>  // error in the BUILD system.
>>  //
>>  ASSERT (MatchGuid != NULL);
> 
> Can you try the following:
> 
> - Locate EFI_PCD_PROTOCOL.
> 
> - Call EFI_PCD_PROTOCOL.GetNextTokenSpace() in a loop, until you find
>  the GUID of your own token space GUID, or the function returns an
>  error.
> 
> - If your token space GUID has been found, call PcdGetEx8().
> 

Laszlo,

I think it may be better to call PCD_PROTOCOL.GetNextToken() as the GUID and Token spaces are both sparse name spaces. The Get*Ex() functions don't return errors so I guess this is your only choice. You could probably make a MyLibGet*Ex() function that returns EFI_STATUS, and returns the data via an arg.   MyLibGet*Ex() could abstract the PCD_PROTOCOL.GetNextToken() check, and it could also probably abstract grabbing the protocol. 

FYI it looks like the function header is much more description for GetNextToken() in PCD_PROTOCOL [1] vs EFI_PCD_PROTOCOL [2]. Also EFI_PCD_PROTOCOL does not have the *Ex functions, so you need PCD_PROTOCOL anyway to have access to the *Ex versions of the API.

[1] https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Pcd.h
[2] https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/PiPcd.h

Thanks,

Andrew Fish

> Thanks,
> Laszlo
> 
> 
> 
> 


  reply	other threads:[~2020-01-23 21:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-23  1:37 PCD EX interface Ken Taylor
2020-01-23 11:21 ` [edk2-devel] " Laszlo Ersek
2020-01-23 21:08   ` Andrew Fish [this message]
2020-01-24 10:14     ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5D2A47A2-6DCE-448B-A5BA-14BE7BBA464B@apple.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox