Bret, We like the new functionality. Our concern is our customers / we will need to modify all of the code that are consumers of EDKII_VARIABLE_LOCK_PROTOCOL to use the new protocols. If you could

Leif, A few comments included below. Thanks, Mike

Expanding the audience beyond the RFC list…. If no one has additional input, I’ll try to start formatting these as patches later this week. Thanks! - Bret Sent: Tuesday, January 28, 2020 5:36

All, VariablePolicy is our proposal for an expanded “VarLock-like” interface to constrain and govern platform variables. I brought this up back in May to get initial comments on the interface and

s/oorg/org/ This seems to require that the specifications be available as something "patchable" (e.g. GitBook source code), and offered in some public git repo. How does this play together with

This is a proposal for a process by which new features can be added to UEFI forum specifications after first having been designed and prototyped in the open. This process lets changes and the

I agree -- I expect that most if not all platform DSC files will need updates. That's because the most frugal approach for a platform is to use the self-contained UefiDevicePathLib instance only in

So, the impact is every platform DSC needs to be updated to reference the correct path of the UefiDevicePath lib after your merge. Let's wait for at least 2 weeks for feedbacks. Thanks, Ray Sent:

Ray, I prefer to merge these two lib instance into one folder and remove the duplicated code. I can change all the required change in open source repo. But not sure how many close source platforms

Zhichao, What's your recommendation regarding this? Back to your 2nd question, drivers/applications consuming UefiDevicePathLibOptionalDevicePathProtocol can firstly use the firmware built-in

HI all, REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298 In the MdePkg, there are two folder for the DevicePathLib: 1. MdePkg\Library\UefiDevicePathLib 2.

Thanks, Mike! I was in the process of sending out the review, so, went ahead and blasted the review email. I will look at your suggestions in the meantime. ~ Amol

Amol, All the APIs are available from BaseCryptLib. I agree that implementations of HashLib on top of other crypto libs would require a different implementation of the library instance and if all

Hi Mike, In my proposal, only the API that is selected by PcdSystemHashPolicy will be registered and it will not matter whether other hashing algorithms are supported or not. Whereas, in your

Amol, Your style requires bigger source changes to exiting modules to switch from BaseCryptLib to HashLib. Your style also required a loop to search for matching API on every call. Mine will

Thanks, Mike! Based on your suggestion below and keeping in line with our implementation, I would like to recommend the following changes. I will make those and upload for review: The PCD defined

Amol, I would recommend a different set of APIs in the HashLib class. Instead of doing a registration, define a PCD to select the hash type and have the generic HashLib function call the

Hello everyone, Checking if there are any review comments for https://github.com/ansukerk/edk2. Do I need to submit patches in any other format? Thanks, Amol

Yeah, if we don't want to carry Cmocka in edk2, there's a necessary trade off of having to keep a dependency for the host-based tests. You wouldn't need this dependency for a simple shell-based test,

Hi Bret, No. I did not do that step yet. I will try that next. I was just trying to build the new DSC in the MdePkg. The external dependency for a set of simple lib API unit tests in MdePkg was