From: "Ni, Ray" <ray.ni@intel.com>
To: Ashish Singhal <ashishsingha@nvidia.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"Wang, Jian J" <jian.j.wang@intel.com>,
"Wu, Hao A" <hao.a.wu@intel.com>,
"Gao, Zhichao" <zhichao.gao@intel.com>
Subject: Re: [PATCH v3] MdeModulePkg: Add Platform Boot Options Protocol
Date: Wed, 18 Dec 2019 08:42:30 +0000 [thread overview]
Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C3A190C@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <DM6PR12MB332409586D5E7D03FF393416BA530@DM6PR12MB3324.namprd12.prod.outlook.com>
I am ok with adding EDKII_PLATFORM_BOOT_MANAGER_PROTOCOL.
> -----Original Message-----
> From: Ashish Singhal <ashishsingha@nvidia.com>
> Sent: Wednesday, December 18, 2019 12:22 PM
> To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A
> <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>
> Subject: RE: [PATCH v3] MdeModulePkg: Add Platform Boot Options Protocol
>
> Ray,
>
> I did not name the protocol this way because EmbeddedPkg already describes a protocol with a similar name that is
> PLATFORM_BOOT_MANAGER_PROTOCOL. If you think we can still go ahead with new protocol named
> EDKII_PLATFORM_BOOT_MANAGER_PROTOCOL, I can make the necessary changes.
>
> I agree with your suggestion about unifying both functions into a single one as well.
>
> Thanks
> Ashish
>
> -----Original Message-----
> From: Ni, Ray <ray.ni@intel.com>
> Sent: Tuesday, December 17, 2019 5:55 PM
> To: Ashish Singhal <ashishsingha@nvidia.com>; devel@edk2.groups.io; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A
> <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>
> Subject: RE: [PATCH v3] MdeModulePkg: Add Platform Boot Options Protocol
>
> External email: Use caution opening links or attachments
>
>
> Ashish,
> I prefer EDKII_PLATFORM_BOOT_MANAGER_PROTOCOL and could have two fields for this protocol for now:
> Revision and RefreshAllBootOption (IN Options, IN OptionCount, OUT UpdatedOptions, OUT UpdatedOptionCount)
> Usually EDKII puts Count in second and buffer in first.
>
> The reason of using EDKII_PLATFORM_BOOT_MANAGER_PROTOCOL as the new protocol name is in future we could
> increase the revision and put more platform hook API in this protocol.
>
> The reason of combining two APIs to one RefreshAllBootOption() is when I checked the code change below, I see no need
> to separate them.
>
> What do you think?
>
> Thanks,
> Ray
>
> > //
> > + // Locate Platform Boot Options Protocol // PlatformBootOptions =
> > + NULL; Status = gBS->LocateProtocol
> > + (&gEdkiiPlatformBootOptionsProtocolGuid,
> > + NULL,
> > + (VOID **)&PlatformBootOptions); if
> > + (!EFI_ERROR (Status)) {
> > + //
> > + // If found, call platform specific overrides to auto enumerated
> > + // boot options.
> > + //
> > + Status = PlatformBootOptions->OverridePlatformBootOptions ((CONST UINTN)BootOptionCount,
> > + (CONST EFI_BOOT_MANAGER_LOAD_OPTION *)BootOptions,
> > + &UpdatedBootOptionCount,
> > + &UpdatedBootOptions);
> > + if (!EFI_ERROR (Status)) {
> > + EfiBootManagerFreeLoadOptions (BootOptions, BootOptionCount);
> > + BootOptions = UpdatedBootOptions;
> > + BootOptionCount = UpdatedBootOptionCount;
> > + }
> > +
> > + //
> > + // Call platform specific override to remove invalid boot options from NV
> > + //
> > + Status = PlatformBootOptions->RemoveInvalidPlatformNvBootOptions ((CONST UINTN)NvBootOptionCount,
> > + (CONST EFI_BOOT_MANAGER_LOAD_OPTION *)NvBootOptions,
> > + &UpdatedBootOptionCount,
> > + &UpdatedBootOptions);
> > + if (!EFI_ERROR (Status)) {
> > + EfiBootManagerFreeLoadOptions (NvBootOptions, NvBootOptionCount);
> > + NvBootOptions = UpdatedBootOptions;
> > + NvBootOptionCount = UpdatedBootOptionCount;
> > + }
> > + }
> > +
>
> -----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and may contain
> confidential information. Any unauthorized review, use, disclosure or distribution
> is prohibited. If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> -----------------------------------------------------------------------------------
next prev parent reply other threads:[~2019-12-18 8:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-17 20:36 [PATCH v3] MdeModulePkg: Add Platform Boot Options Protocol Ashish Singhal
2019-12-18 0:55 ` Ni, Ray
2019-12-18 4:21 ` Ashish Singhal
2019-12-18 8:42 ` Ni, Ray [this message]
2019-12-18 19:14 ` Ashish Singhal
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=734D49CCEBEEF84792F5B80ED585239D5C3A190C@SHSMSX104.ccr.corp.intel.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