Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

["Ashish Singhal" <ashishsingha@nvidia.com>]

Reconciling the email chain from devel.io portal as it does not send email to individual participants.

On Nov 5, 2019, at 5:19 PM, Jeff Brasen <jbrasen@...> wrote:

Wouldn't having a variable that we create and delete on every boot put unnecessary stress on the SPI-NOR that the variable store lives on?
What about the alternative approach where we allow the platform code to modify the attributes of the auto created variable to disable it with hidden/!active but still match for detection purposes so that it doesn't delete and recreate the modified variable each boot? That way all the logic on what to disable can still be in the platform code and all the existing logic in the boot manager can stay basically the same?

What changes every boot that forces the variable to need to get modified? 

I would assume the NOR driver is smart enough to not update a variable that is not changing. 

The custom BDS could could only create the variable for this device if it does not exist. 

Thanks,

Andrew Fish

Thanks,

Jeff

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com> 
Sent: Tuesday, November 5, 2019 12:24 PM
To: Ashish Singhal <ashishsingha@nvidia.com>; Andrew Fish <afish@apple.com>
Cc: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>; Mike Kinney <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

On 11/05/19 19:00, Ashish Singhal wrote:

> I agree that I can use the platform boot manager protocol to modify 
> the boot variable and give the custom optional data I need, but that 
> would not stop UefiBootManagerLib from creating another boot option 
> with mBmAutoCreateBootOptionGuid as the optional data on the next 
> bootup which I would have to delete every time in the platform boot 
> manager driver.

>From a purely pragmatic perspective, I would act exactly like you describe above. I'm not saying that this is the cleanest design, or that it has the best performance. However, it also does not introduce technical debt -- it's not a "wrong" thing to do --, and (from past
experience) keeping it 100% in platform code produces the least amount of friction, and allows for the smoothest development. Extending UefiBootManagerLib has always been an uphill battle.

Thanks
Laszlo

-----------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------