Mike, Looks good as a starting point! Acked-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...> I do have a few questions on this sentence: "Specification text changes are held within the

A version of this Wiki page is also provided here for review: https://github.com/mdkinney/edk2/wiki/EDK-II-Code-First-Process Mike

I find that regrettable, because in some (rare!) cases, a commit would really deserve both tags. I agree this is a good general principle; it's always good to make a patch author think explicitly

I'd like to suggest "Type: " rather than "TYPE: ". Furthermore, assuming a consistent use of the "Type: " name (at the beginning of the line), do we really need the '**' value prefix/suffix? On one

Hello Mike, Thanks for your feedback. There are several levels of intent behind our proposal.The one that you mentioned (search and identify commits by certain tag attribute) is important, but not

Hi Artem, We discussed this topic briefly in the EDK II Community meeting this morning With Felix. For the tags topic, I believe the feature being asked for here is a simple way to identify and

On Sat, Aug 1, 2020 at 03:47 PM, Laszlo Ersek wrote: On 08/01/20 00:19, Artem Shchygel wrote:> Hi, All>> In this RFC we're proposing slight changes to Git commit message format tomake it more

Hints are very welcome, but not in subject lines. Please use Name: value Name: value # comment style tags near the end of the commit messages instead. Subject lines are primarily for human

Hi, All In this RFC we're proposing slight changes to Git commit message format to make it more informative and more friendly for automation tools. Here is the list of changes proposed Start subject

Hi Sean, The binary to be signed is a blob of data to be consumed by BIOS. In the example mentioned the signed blob is packaged in an FV, but the solution should be flexible to work with other

Thanks for the info. I would like to break my continued comments into two distinct parts. 1. Still interested in why we need new abstractions for the data blob. From your use case i would suggest

Hi Ethin Unfortunately I didn't have a chance to continue this work on the last months. Code sample can be found here: https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility At YouTube

Hi Divneil, Good News, thanks for your update.

Hello all, Raising this from (the seeming) silence it's been in since the 30th of Oct. of 2019. What is the status on this? Also, is there a bit of source code you guys can share with me for

Hi Guomin, I have moved forward from the last discussion, and the tools work okay for RSA2048/SHA256. Once I have the next update, I will notify it here. Regards, Divneil

Well as far as I'm concerned it's a simple rule. If a structure is serialized from RAM into a disk file, or to the network, then the structure should be packed. If it's only exchanged in RAM, on a

Curtis, Not sure I fully follow your proposal. Can you provide more on the use case? Is the "blob" a FV or is the signed_sub_region a raw section in a ffs file? or something else like binary at

Thanks for the link.  I agree that this change will make the StatusCodeHandler driver more modular, and is a step in the right direction. But I think it could go further, with almost no additional

Hi Laszlo, Please see my comments below. Thanks, Amol

Hi Brian, In this new design, we still use register status code handler Protocol/Ppi to register the handler logic. We just want to change the StatusCodeHandler driver. We try to split the register