rfc@edk2.groups.io

Home Messages Hashtags

Messages

Between

and

Re: [edk2-devel] [Wiki][Patch V2] Add EDK II Code First Process Wiki Page

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

By Michael D Kinney · #381 ·

Re: Git commit message RFC

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

By Laszlo Ersek · #380 ·

Re: Git commit message RFC

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

By Laszlo Ersek · #379 ·

Re: Git commit message RFC

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

By Artem Shchygel · #378 ·

Re: Git commit message RFC

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

By Michael D Kinney · #377 ·

Re: Git commit message RFC

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

By Artem Shchygel · #376 ·

Re: Git commit message RFC

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

By Laszlo Ersek · #375 ·

Git commit message RFC

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

By Artem Shchygel · #374 ·

Re: SubRegionAuthLib RFC

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

By Mackay, Curtis A <curtis.a.mackay@...> · #373 ·

Re: SubRegionAuthLib RFC

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

By Sean · #372 ·

Re: UEFI accessibility mandate

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

By Rafael Machado <rafaelrodrigues.machado@...> · #371 ·

Re: PKCS7 Authenticated Variable Enrollment

Hi Divneil, Good News, thanks for your update.

By Guomin Jiang · #370 ·

Re: UEFI accessibility mandate

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

By Ethin Probst · #369 ·

Re: PKCS7 Authenticated Variable Enrollment

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

By Wadhawan, Divneil R · #368 ·

Re: SubRegionAuthLib RFC

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

By Laszlo Ersek · #367 ·

Re: SubRegionAuthLib RFC

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

By Sean · #366 ·

Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

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

By Brian J. Johnson · #365 ·

Re: SubRegionAuthLib RFC

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

By Sukerkar, Amol N · #364 ·

Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

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

By Dong, Eric <eric.dong@...> · #363 ·

Re: SubRegionAuthLib RFC

Hi, I don't have a stake in this feature, but because the presentation isn't long, I've briefly skimmed it: - It's unclear whether the public data structures describe a wire format. If they do, they

By Laszlo Ersek · #362 ·

421 - 440 of 800

Home Hashtags About Features Pricing Updates Terms Help Twitter