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
>
>
>
>
next prev parent 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