Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Michael Kubacki]

On 5/3/2024 4:38 PM, Michael D Kinney wrote:




-Original Message-
From: Kinney, Michael D 
Sent: Friday, May 3, 2024 1:13 PM
To: Pedro Falcato 
Cc: r...@edk2.groups.io; devel@edk2.groups.io; Leif Lindholm
; Andrew Fish (af...@apple.com) ;
Kinney, Michael D 
Subject: RE: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code
Review from email to GitHub Pull Requests on 5-24-2024




-Original Message-
From: Pedro Falcato 
Sent: Friday, May 3, 2024 10:39 AM
To: Kinney, Michael D 
Cc: r...@edk2.groups.io; devel@edk2.groups.io; Leif Lindholm
; Andrew Fish (af...@apple.com) 
Subject: Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code
Review from email to GitHub Pull Requests on 5-24-2024

On Thu, May 2, 2024 at 7:17 PM Kinney, Michael D
 wrote:





-Original Message-
From: r...@edk2.groups.io  On Behalf Of Pedro

Falcato

Sent: Thursday, May 2, 2024 10:51 AM
To: devel@edk2.groups.io; Kinney, Michael D



Cc: r...@edk2.groups.io; Leif Lindholm ; Andrew

Fish

(af...@apple.com) 
Subject: Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore

Code

Review from email to GitHub Pull Requests on 5-24-2024

On Wed, May 1, 2024 at 6:44 PM Michael D Kinney via groups.io
 wrote:



* All contributors, maintainers, and reviewers must have GitHub

IDs.

* The commit message would no longer require Cc:, Reviewed-by:,

Acked-

by:

   or Tested-by: tags.  The only required tag would be Signed-

off-

by.


I'd just like to note that losing the CC:, Reviewed-by:, etc is a

big

loss. Gerrit auto-adds Rb's, github PR's do not (I'd guess there's

a

way to pull that off with github actions, but I haven't looked).

It'll

be a mess if I have to go through online GH PR backlogs just to

find

who to CC/add-to-review. It kills the decentralized bit off of git

too

:)



Can you provide more details on the impact of the loss?


In my view, commits should be fairly self-describing. What changes,
why, are obvious, but who looked at it, who reviewed it, who was cc'd
but didn't respond, who tested are also pretty important. Git is
supposed to be decentralized, let's not forget. If we ever migrate
from GH, if GH ever goes down, if the links ever go down, you'll never
be able to know who looked at it. If you're looking at an EDK2 commit
deep into an Intel-internal fork, you won't know what "PR #478" is
(heck, rebase-and-merge doesn't reference PRs either).

Side-note: How are we supposed to find the PR for a given commit?
Searching doesn't seem to work well. For instance, I picked a random
non-trivial commit out of the current open PRs:
MdeModulePkg/Bus/Spi/SpiBus: Adding SpiBus Drivers.


https://github.com/tianocore/edk2/pulls?q=is%3Apr+is%3Aopen+MdeModulePkg

%2FBus%2FSpi%2FSpiBus%3A+Adding+SpiBus+Drivers
has no matches?


If you have the sha of the commit, you can search in GitHub

For example, I selected a commit at random from recent edk2 commit
history:

https://github.com/tianocore/edk2/commit/032830e96841f2a752e364378c
3428ac5d2f59d1

Goto the "Pull Requests" tab for the repo and in the "Filters" search
box enter

is:pr is:merged 

In this example:

is:pr is:merged 032830e96841f2a752e364378c3428ac5d2f59d1

This returns a single hit on PR #5560

https://github.com/tianocore/edk2/pull/5560

There is also a 'gh' command line utility that can be used to write
small scripts to collect this information


Here is the equivalent query and output using 'gh' CLI command:

 gh pr list --repo tianocore/edk2 --state merged --search 
032830e96841f2a752e364378c3428ac5d2f59d1

 Showing 1 of 1 pull request in tianocore/edk2 that matches your search

 ID TITLE BRANCHCREATED AT
 #5560  Loongcpu  niruiyu:loongcpu  about 17 days ago


I didn't see this explicitly mentioned but the easiest way to get to the 
PR if you already have a commit hash/URL like 
https://github.com/tianocore/edk2/commit/032830e is to click the PR link 
next to the branch name at the bottom of the commit message.


In that commit you'll see: "master (#5560)"

Where "#5560" is the PR number and the link to the PR.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118566): https://edk2.groups.io/g/devel/message/118566
Mute This Topic: https://groups.io/mt/105873467/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] edk2-test Release candidate 2: edk2-test-rc2_202405 // RE: [PATCH v2 0/4] TCG2 protocol clean up

[G Edhaya Chandran]

Hi All,

   A new release candidate is published after upstreaming Stuart's commits on 
build cleanup.
https://github.com/tianocore/edk2-test/tree/edk2-test-rc2_202405

The updates since the old tag are the following commits in the patch series:
[PATCH v2 0/4] TCG2 protocol clean up 
(groups.io)

The release candidate may be used for any further testing.

With Warm Regards,
Edhay



> -Original Message-
> From: G Edhaya Chandran
> Sent: Tuesday, April 23, 2024 4:52 AM
> To: Heinrich Schuchardt 
> Cc: alex_...@phoenix.com; david_wri...@phoenix.com;
> lic...@loongson.cn; Stuart Yoder ;
> devel@edk2.groups.io; gao...@byosoft.com.cn
> Subject: RE: [PATCH v2 0/4] TCG2 protocol clean up
>
> Hi Heinrich,
>
>Yes. A new release candidate shall be published after review and upstream
> of the patches.
> Will further send an update.
>
> With Warm Regards,
> Edhay
>
>
> > -Original Message-
> > From: Heinrich Schuchardt 
> > mailto:heinrich.schucha...@canonical.com>>
> > Sent: Tuesday, April 23, 2024 12:46 AM
> > To: G Edhaya Chandran 
> > mailto:edhaya.chand...@arm.com>>
> > Cc: alex_...@phoenix.com; 
> > david_wri...@phoenix.com;
> > lic...@loongson.cn; Stuart Yoder 
> > mailto:stuart.yo...@arm.com>>;
> > devel@edk2.groups.io; 
> > gao...@byosoft.com.cn
> > Subject: Re: [PATCH v2 0/4] TCG2 protocol clean up
> >
> > On 4/16/24 16:53, Stuart Yoder wrote:
> > > This patch series cleans up some issues found when building
> > > edk2-test with a non-GCC compiler:
> > >-TPMT_HA struct had an error due to incorrect use of C flexible
> > > array
> > member
> > >-compute struct member offsets using OFFSET_OF, which is not GCC
> specific
> > >-clean up of #pragma pack in one file
> > >-resolve type conversion warnings
> > >
> > > Patches are in github here:
> > > https://github.com/stuyod01/edk2-test/tree/tcg2-cleanup
> > >
> > > Version 2
> > >-add SM3 hash type to TPM2.h
> > >-resolve type conversion warnings
> > >
> > > Stuart Yoder (4):
> > >uefi-sct/SctPkg: TCG2 Protocol: correct definition of TPMT_HA struct
> > >uefi-sct/SctPkg: TCG2 Protocol: use OFFSET_OF for computing offsets
> > >uefi-sct/SctPkg: TCG2 Protocol: #pragma pack cleanup
> > >uefi-sct/SctPkg: TCG2 Protocol: clean up type conversion warnings
> > >
> > >   uefi-
> >
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/TCG2/BlackBoxTest/TCG2ProtocolBBTe
> > st.h|  3 +--
> > >   uefi-sct/SctPkg/UEFI/Protocol/TCG2.h
> > >  | 17
> > +++--
> > >   uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/Protocol/TCG2/BlackBoxTest/TCG2ProtocolBB
> > Te stConformance.c | 25 +---
> > >   3 files changed, 27 insertions(+), 18 deletions(-)
> > >
> >
> > Hello Edhaya,
> >
> > Will we have another release candidate with these patches included?
> >
> > Best regards
> >
> > Heinrich

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118565): https://edk2.groups.io/g/devel/message/118565
Mute This Topic: https://groups.io/mt/105898910/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Michael D Kinney]

> -Original Message-
> From: Kinney, Michael D 
> Sent: Friday, May 3, 2024 1:13 PM
> To: Pedro Falcato 
> Cc: r...@edk2.groups.io; devel@edk2.groups.io; Leif Lindholm
> ; Andrew Fish (af...@apple.com) ;
> Kinney, Michael D 
> Subject: RE: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code
> Review from email to GitHub Pull Requests on 5-24-2024
> 
> 
> 
> > -Original Message-
> > From: Pedro Falcato 
> > Sent: Friday, May 3, 2024 10:39 AM
> > To: Kinney, Michael D 
> > Cc: r...@edk2.groups.io; devel@edk2.groups.io; Leif Lindholm
> > ; Andrew Fish (af...@apple.com) 
> > Subject: Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code
> > Review from email to GitHub Pull Requests on 5-24-2024
> >
> > On Thu, May 2, 2024 at 7:17 PM Kinney, Michael D
> >  wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: r...@edk2.groups.io  On Behalf Of Pedro
> > Falcato
> > > > Sent: Thursday, May 2, 2024 10:51 AM
> > > > To: devel@edk2.groups.io; Kinney, Michael D
> > 
> > > > Cc: r...@edk2.groups.io; Leif Lindholm ; Andrew
> > Fish
> > > > (af...@apple.com) 
> > > > Subject: Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore
> > Code
> > > > Review from email to GitHub Pull Requests on 5-24-2024
> > > >
> > > > On Wed, May 1, 2024 at 6:44 PM Michael D Kinney via groups.io
> > > >  wrote:
> > 
> > > > > * All contributors, maintainers, and reviewers must have GitHub
> > IDs.
> > > > > * The commit message would no longer require Cc:, Reviewed-by:,
> > Acked-
> > > > by:
> > > > >   or Tested-by: tags.  The only required tag would be Signed-
> off-
> > by.
> > > >
> > > > I'd just like to note that losing the CC:, Reviewed-by:, etc is a
> > big
> > > > loss. Gerrit auto-adds Rb's, github PR's do not (I'd guess there's
> a
> > > > way to pull that off with github actions, but I haven't looked).
> > It'll
> > > > be a mess if I have to go through online GH PR backlogs just to
> find
> > > > who to CC/add-to-review. It kills the decentralized bit off of git
> > too
> > > > :)
> > > >
> > >
> > > Can you provide more details on the impact of the loss?
> >
> > In my view, commits should be fairly self-describing. What changes,
> > why, are obvious, but who looked at it, who reviewed it, who was cc'd
> > but didn't respond, who tested are also pretty important. Git is
> > supposed to be decentralized, let's not forget. If we ever migrate
> > from GH, if GH ever goes down, if the links ever go down, you'll never
> > be able to know who looked at it. If you're looking at an EDK2 commit
> > deep into an Intel-internal fork, you won't know what "PR #478" is
> > (heck, rebase-and-merge doesn't reference PRs either).
> >
> > Side-note: How are we supposed to find the PR for a given commit?
> > Searching doesn't seem to work well. For instance, I picked a random
> > non-trivial commit out of the current open PRs:
> > MdeModulePkg/Bus/Spi/SpiBus: Adding SpiBus Drivers.
> >
> https://github.com/tianocore/edk2/pulls?q=is%3Apr+is%3Aopen+MdeModulePkg
> > %2FBus%2FSpi%2FSpiBus%3A+Adding+SpiBus+Drivers
> > has no matches?
> 
> If you have the sha of the commit, you can search in GitHub
> 
> For example, I selected a commit at random from recent edk2 commit
> history:
> 
>   https://github.com/tianocore/edk2/commit/032830e96841f2a752e364378c
> 3428ac5d2f59d1
> 
> Goto the "Pull Requests" tab for the repo and in the "Filters" search
> box enter
> 
>   is:pr is:merged 
> 
> In this example:
> 
>   is:pr is:merged 032830e96841f2a752e364378c3428ac5d2f59d1
> 
> This returns a single hit on PR #5560
> 
>   https://github.com/tianocore/edk2/pull/5560
> 
> There is also a 'gh' command line utility that can be used to write
> small scripts to collect this information

Here is the equivalent query and output using 'gh' CLI command:

gh pr list --repo tianocore/edk2 --state merged --search 
032830e96841f2a752e364378c3428ac5d2f59d1

Showing 1 of 1 pull request in tianocore/edk2 that matches your search

ID TITLE BRANCHCREATED AT
#5560  Loongcpu  niruiyu:loongcpu  about 17 days ago


> 
> >
> > >
> > > I am curious how other GitHub projects handle this topic. I see it
> >
> > I don't think they do, sadly. But I also don't know many people with a
> > positive opinion on GH PRs :)
> >
> > 
> > > > It is sad that we're moving to PRs after I finally got a nice and
> > > > sane(ish!) email workflow (openfw.io + b4). Otherwise, no
> > objections,
> > > > it's better than edk2.git's half-email half-PR frankenprocess.
> > > > I'd guess this change only encompasses edk2.git? How about the
> other
> > > > repos? Any timeline for those?
> > >
> > > The plan is to apply this to all repos, one at a time.  Need to get
> > the
> > > revised process documented and working in one repo before applying
> to
> > all.
> >
> > Gotcha, thanks!
> >
> > --
> > Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online 

Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Michael D Kinney]

> -Original Message-
> From: Pedro Falcato 
> Sent: Friday, May 3, 2024 10:39 AM
> To: Kinney, Michael D 
> Cc: r...@edk2.groups.io; devel@edk2.groups.io; Leif Lindholm
> ; Andrew Fish (af...@apple.com) 
> Subject: Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code
> Review from email to GitHub Pull Requests on 5-24-2024
> 
> On Thu, May 2, 2024 at 7:17 PM Kinney, Michael D
>  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: r...@edk2.groups.io  On Behalf Of Pedro
> Falcato
> > > Sent: Thursday, May 2, 2024 10:51 AM
> > > To: devel@edk2.groups.io; Kinney, Michael D
> 
> > > Cc: r...@edk2.groups.io; Leif Lindholm ; Andrew
> Fish
> > > (af...@apple.com) 
> > > Subject: Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore
> Code
> > > Review from email to GitHub Pull Requests on 5-24-2024
> > >
> > > On Wed, May 1, 2024 at 6:44 PM Michael D Kinney via groups.io
> > >  wrote:
> 
> > > > * All contributors, maintainers, and reviewers must have GitHub
> IDs.
> > > > * The commit message would no longer require Cc:, Reviewed-by:,
> Acked-
> > > by:
> > > >   or Tested-by: tags.  The only required tag would be Signed-off-
> by.
> > >
> > > I'd just like to note that losing the CC:, Reviewed-by:, etc is a
> big
> > > loss. Gerrit auto-adds Rb's, github PR's do not (I'd guess there's a
> > > way to pull that off with github actions, but I haven't looked).
> It'll
> > > be a mess if I have to go through online GH PR backlogs just to find
> > > who to CC/add-to-review. It kills the decentralized bit off of git
> too
> > > :)
> > >
> >
> > Can you provide more details on the impact of the loss?
> 
> In my view, commits should be fairly self-describing. What changes,
> why, are obvious, but who looked at it, who reviewed it, who was cc'd
> but didn't respond, who tested are also pretty important. Git is
> supposed to be decentralized, let's not forget. If we ever migrate
> from GH, if GH ever goes down, if the links ever go down, you'll never
> be able to know who looked at it. If you're looking at an EDK2 commit
> deep into an Intel-internal fork, you won't know what "PR #478" is
> (heck, rebase-and-merge doesn't reference PRs either).
> 
> Side-note: How are we supposed to find the PR for a given commit?
> Searching doesn't seem to work well. For instance, I picked a random
> non-trivial commit out of the current open PRs:
> MdeModulePkg/Bus/Spi/SpiBus: Adding SpiBus Drivers.
> https://github.com/tianocore/edk2/pulls?q=is%3Apr+is%3Aopen+MdeModulePkg
> %2FBus%2FSpi%2FSpiBus%3A+Adding+SpiBus+Drivers
> has no matches?

If you have the sha of the commit, you can search in GitHub

For example, I selected a commit at random from recent edk2 commit history:


https://github.com/tianocore/edk2/commit/032830e96841f2a752e364378c3428ac5d2f59d1

Goto the "Pull Requests" tab for the repo and in the "Filters" search box enter 

is:pr is:merged 

In this example:

is:pr is:merged 032830e96841f2a752e364378c3428ac5d2f59d1

This returns a single hit on PR #5560

https://github.com/tianocore/edk2/pull/5560

There is also a 'gh' command line utility that can be used to write
small scripts to collect this information 

> 
> >
> > I am curious how other GitHub projects handle this topic. I see it
> 
> I don't think they do, sadly. But I also don't know many people with a
> positive opinion on GH PRs :)
> 
> 
> > > It is sad that we're moving to PRs after I finally got a nice and
> > > sane(ish!) email workflow (openfw.io + b4). Otherwise, no
> objections,
> > > it's better than edk2.git's half-email half-PR frankenprocess.
> > > I'd guess this change only encompasses edk2.git? How about the other
> > > repos? Any timeline for those?
> >
> > The plan is to apply this to all repos, one at a time.  Need to get
> the
> > revised process documented and working in one repo before applying to
> all.
> 
> Gotcha, thanks!
> 
> --
> Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118563): https://edk2.groups.io/g/devel/message/118563
Mute This Topic: https://groups.io/mt/105873467/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] IntelFsp2Pkg/PatchFv.py: FIX for GCC 32BIT build error

[Nate DeSimone]

Pushed as 248aa15

> -Original Message-
> From: Duggapu, Chinni B 
> Sent: Monday, April 22, 2024 9:03 PM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Desimone, Nathaniel L
> ; Duggapu, Chinni B
> ; S, Ashraf Ali ; Kuo,
> Ted 
> Subject: [PATCH] IntelFsp2Pkg/PatchFv.py: FIX for GCC 32BIT build error
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4762
> 
> Map file generating 8 byte address offset is not matched with the pattern
> defined in patchFv tool resulting build error.
> 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Duggapu Chinni B 
> Cc: Ashraf Ali S 
> Cc: Ted Kuo 
> 
> Signed-off-by: Duggapu Chinni B 
> ---
>  IntelFsp2Pkg/Tools/PatchFv.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/IntelFsp2Pkg/Tools/PatchFv.py b/IntelFsp2Pkg/Tools/PatchFv.py
> index bd9aa71e3c..d35aa1dc9f 100644
> --- a/IntelFsp2Pkg/Tools/PatchFv.py
> +++ b/IntelFsp2Pkg/Tools/PatchFv.py
> @@ -432,7 +432,7 @@ class Symbols:
>  if reportLine.strip().find("Archive member included") != -1:
>  #GCC
>  #0x1d55IoRead8
> -patchMapFileMatchString = 
> r"\s+(0x[0-9a-fA-F]{16})\s+([^\s][^0x][_a-zA-Z0-9\-]+)\s"
> +patchMapFileMatchString = 
> r"\s+(0x[0-9a-fA-F]{8,16})\s+([^\s][^0x][_a-zA-Z0-9\-]+)\s"
>  matchKeyGroupIndex = 2
>  matchSymbolGroupIndex  = 1
>  prefix = '_'
> -- 
> 2.44.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118562): https://edk2.groups.io/g/devel/message/118562
Mute This Topic: https://groups.io/mt/105684430/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Michael D Kinney]

Yes.  Many options on transition.  I would suggest we consider the
following steps.

1) Define a manual process where Maintainers/Reviewers look for 
   new PRs and make sure all the required maintainers/reviewers
   are invited to the review.  Current process has many manual
   steps.  Having this one does not seem like a bad transition 
   option.

2) Add CODEOWNERS support to automate assignment of maintainers
   And enforce maintainer approval requirements.

3) Add REVIEWEWS support to automate assignment of reviewers.

Mike

> -Original Message-
> From: r...@edk2.groups.io  On Behalf Of Michael
> Kubacki
> Sent: Friday, May 3, 2024 10:22 AM
> To: devel@edk2.groups.io; Kinney, Michael D
> ; quic_llind...@quicinc.com;
> marcin.juszkiew...@linaro.org; r...@edk2.groups.io
> Cc: Leif Lindholm ; Andrew Fish (af...@apple.com)
> 
> Subject: Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code
> Review from email to GitHub Pull Requests on 5-24-2024
> 
> Hi Mike,
> 
> I've seen that repo in that past.
> 
> Are the steps defined for what's needed to move to CODEWONERS (and
> REVIEWERS) in terms of technical and process changes needed?
> 
> For example, could we start with CODEOWNERS manually synced to
> Maintainers.txt, Maintainers.txt dropped, and then add REVIEWERS in the
> future with additional actions to verify file coverage, etc.?
> 
> Thanks,
> Michael
> 
> On 5/2/2024 12:24 PM, Michael D Kinney wrote:
> > Hi Michael,
> >
> > I have a version of the auto assignment working, but needs to be
> > migrated to TianoCore and synced with the latest Maintainers.txt.
> >
> > My experience getting this running even as a POC was that it took a
> lot
> > of effort to make sure the best security practices were followed and
> > to configure the empty GitHub App with tokens and permissions. Anytime
> > custom actions are added, resources to implement, validate, and
> > support if they ever fail must be in place.
> >
> > My question is if there is a manual process that can be used to
> > start and these type of automations can be added over time as
> > dedicated resources are identified.
> >
> > Dionna's feedback about contributors not being able to add reviewers
> > to a PR is correct.  Contributors that are not members of the
> > EDK II Maintainers or EDK II Reviewers teams will either need to wait
> > for a Maintainer or Reviewer to add reviewers, or the contributor must
> > be added as an "outside collaborator" by an admin. For a manual
> process
> > this would require Maintainers to monitor new PRs and make sure the
> > correct set of Maintainers and Reviewers are added. Perhaps the
> > contributor can include @GitHubId mentions in the PR for the required
> > maintainers/reviewers so there are email notifications.
> >
> > Details on the auto assignment POC
> > ==
> > It uses CODEOWNERS so maintainers are auto assigned and can use GitHub
> > features to prevent merges without maintainer approval.  The idea is
> to
> > minimize the custom behavior and use as many built-in GitHub features
> as
> > possible.  It then reuses the CODEOWNERS syntax for a new file called
> > REVIEWERS along with some GitHub Actions to auto assign reviewers.
> The
> > actions are run by a registered empty GitHub application so it has a
> > TianoCore organization bot that is executing the actions with
> TianoCore
> > org permissions instead of an individual TianoCore member permissions.
> > Example PR with the bot with the name "tianocore-assign-reviewers"
> > performing assignments:
> >  https://github.com/tianocore/edk2-codereview/pull/91
> >
> > It was activated on this repo to run experiments:
> >  https://github.com/tianocore/edk2-codereview/tree/master/.github
> >
> > Example CODEOWNERS file:
> >  https://github.com/tianocore/edk2-
> codereview/blob/master/.github/CODEOWNERS
> >
> > Example REVIEWERS file using same format as CODEOWNERS
> >  https://github.com/tianocore/edk2-
> codereview/blob/master/.github/REVIEWERS
> >
> > Action to assign reviewers from REVIEWERS file:
> >  https://github.com/tianocore/edk2-
> codereview/blob/master/.github/workflows/AssignReviewers.yml
> >
> >  Depends on: https://github.com/mdkinney/github-action-assign-
> reviewers
> >
> > Action to verify that all files in a repo have CODEOWNES coverage
> >  https://github.com/tianocore/edk2-
> codereview/blob/master/.github/workflows/CheckCodeOwnerFiles.yml
> >
> > Action to verify that Maintainers.txt, CODEOWNERS, and REVIEWERS are
> synced.
> > This is to support transition from using Maintainers.txt to using
> CODEOWNERS
> > and REVIEWERS and can be dropped when Maintainers.txt is removed.
> >  https://github.com/tianocore/edk2-
> codereview/blob/master/.github/workflows/CheckCodeOwnerMaintainers.yml
> >
> >  Depends on: https://github.com/mdkinney/github-action-check-
> codeowners-maintainers
> >
> > Thanks,
> >
> > Mike
> >
> >> -Original Message-
> >> From: 

Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Pedro Falcato]

On Thu, May 2, 2024 at 7:17 PM Kinney, Michael D
 wrote:
>
>
>
> > -Original Message-
> > From: r...@edk2.groups.io  On Behalf Of Pedro Falcato
> > Sent: Thursday, May 2, 2024 10:51 AM
> > To: devel@edk2.groups.io; Kinney, Michael D 
> > Cc: r...@edk2.groups.io; Leif Lindholm ; Andrew Fish
> > (af...@apple.com) 
> > Subject: Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code
> > Review from email to GitHub Pull Requests on 5-24-2024
> >
> > On Wed, May 1, 2024 at 6:44 PM Michael D Kinney via groups.io
> >  wrote:

> > > * All contributors, maintainers, and reviewers must have GitHub IDs.
> > > * The commit message would no longer require Cc:, Reviewed-by:, Acked-
> > by:
> > >   or Tested-by: tags.  The only required tag would be Signed-off-by.
> >
> > I'd just like to note that losing the CC:, Reviewed-by:, etc is a big
> > loss. Gerrit auto-adds Rb's, github PR's do not (I'd guess there's a
> > way to pull that off with github actions, but I haven't looked). It'll
> > be a mess if I have to go through online GH PR backlogs just to find
> > who to CC/add-to-review. It kills the decentralized bit off of git too
> > :)
> >
>
> Can you provide more details on the impact of the loss?

In my view, commits should be fairly self-describing. What changes,
why, are obvious, but who looked at it, who reviewed it, who was cc'd
but didn't respond, who tested are also pretty important. Git is
supposed to be decentralized, let's not forget. If we ever migrate
from GH, if GH ever goes down, if the links ever go down, you'll never
be able to know who looked at it. If you're looking at an EDK2 commit
deep into an Intel-internal fork, you won't know what "PR #478" is
(heck, rebase-and-merge doesn't reference PRs either).

Side-note: How are we supposed to find the PR for a given commit?
Searching doesn't seem to work well. For instance, I picked a random
non-trivial commit out of the current open PRs:
MdeModulePkg/Bus/Spi/SpiBus: Adding SpiBus Drivers.
https://github.com/tianocore/edk2/pulls?q=is%3Apr+is%3Aopen+MdeModulePkg%2FBus%2FSpi%2FSpiBus%3A+Adding+SpiBus+Drivers
has no matches?

>
> I am curious how other GitHub projects handle this topic. I see it

I don't think they do, sadly. But I also don't know many people with a
positive opinion on GH PRs :)


> > It is sad that we're moving to PRs after I finally got a nice and
> > sane(ish!) email workflow (openfw.io + b4). Otherwise, no objections,
> > it's better than edk2.git's half-email half-PR frankenprocess.
> > I'd guess this change only encompasses edk2.git? How about the other
> > repos? Any timeline for those?
>
> The plan is to apply this to all repos, one at a time.  Need to get the
> revised process documented and working in one repo before applying to all.

Gotcha, thanks!

-- 
Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118560): https://edk2.groups.io/g/devel/message/118560
Mute This Topic: https://groups.io/mt/105873467/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Michael Kubacki]

Hi Mike,

I've seen that repo in that past.

Are the steps defined for what's needed to move to CODEWONERS (and 
REVIEWERS) in terms of technical and process changes needed?


For example, could we start with CODEOWNERS manually synced to 
Maintainers.txt, Maintainers.txt dropped, and then add REVIEWERS in the 
future with additional actions to verify file coverage, etc.?


Thanks,
Michael

On 5/2/2024 12:24 PM, Michael D Kinney wrote:

Hi Michael,

I have a version of the auto assignment working, but needs to be
migrated to TianoCore and synced with the latest Maintainers.txt.

My experience getting this running even as a POC was that it took a lot
of effort to make sure the best security practices were followed and
to configure the empty GitHub App with tokens and permissions. Anytime
custom actions are added, resources to implement, validate, and
support if they ever fail must be in place.

My question is if there is a manual process that can be used to
start and these type of automations can be added over time as
dedicated resources are identified.

Dionna's feedback about contributors not being able to add reviewers
to a PR is correct.  Contributors that are not members of the
EDK II Maintainers or EDK II Reviewers teams will either need to wait
for a Maintainer or Reviewer to add reviewers, or the contributor must
be added as an "outside collaborator" by an admin. For a manual process
this would require Maintainers to monitor new PRs and make sure the
correct set of Maintainers and Reviewers are added. Perhaps the
contributor can include @GitHubId mentions in the PR for the required
maintainers/reviewers so there are email notifications.

Details on the auto assignment POC
==
It uses CODEOWNERS so maintainers are auto assigned and can use GitHub
features to prevent merges without maintainer approval.  The idea is to
minimize the custom behavior and use as many built-in GitHub features as
possible.  It then reuses the CODEOWNERS syntax for a new file called
REVIEWERS along with some GitHub Actions to auto assign reviewers.  The
actions are run by a registered empty GitHub application so it has a
TianoCore organization bot that is executing the actions with TianoCore
org permissions instead of an individual TianoCore member permissions.
Example PR with the bot with the name "tianocore-assign-reviewers"
performing assignments:
 https://github.com/tianocore/edk2-codereview/pull/91

It was activated on this repo to run experiments:
 https://github.com/tianocore/edk2-codereview/tree/master/.github

Example CODEOWNERS file:
 https://github.com/tianocore/edk2-codereview/blob/master/.github/CODEOWNERS

Example REVIEWERS file using same format as CODEOWNERS
 https://github.com/tianocore/edk2-codereview/blob/master/.github/REVIEWERS

Action to assign reviewers from REVIEWERS file:
 
https://github.com/tianocore/edk2-codereview/blob/master/.github/workflows/AssignReviewers.yml

 Depends on: https://github.com/mdkinney/github-action-assign-reviewers

Action to verify that all files in a repo have CODEOWNES coverage
 
https://github.com/tianocore/edk2-codereview/blob/master/.github/workflows/CheckCodeOwnerFiles.yml

Action to verify that Maintainers.txt, CODEOWNERS, and REVIEWERS are synced.
This is to support transition from using Maintainers.txt to using CODEOWNERS
and REVIEWERS and can be dropped when Maintainers.txt is removed.
 
https://github.com/tianocore/edk2-codereview/blob/master/.github/workflows/CheckCodeOwnerMaintainers.yml

 Depends on: 
https://github.com/mdkinney/github-action-check-codeowners-maintainers

Thanks,

Mike


-Original Message-
From: Michael Kubacki 
Sent: Thursday, May 2, 2024 8:21 AM
To: devel@edk2.groups.io; quic_llind...@quicinc.com;
marcin.juszkiew...@linaro.org; Kinney, Michael D
; r...@edk2.groups.io
Cc: Leif Lindholm ; Andrew Fish (af...@apple.com)

Subject: Re: [edk2-devel] Proposal to switch TianoCore Code Review from
email to GitHub Pull Requests on 5-24-2024

On 5/2/2024 6:34 AM, Leif Lindholm wrote:

On 2024-05-02 07:33, Marcin Juszkiewicz wrote:

W dniu 1.05.2024 o 19:43, Michael D Kinney via groups.io pisze:

I would like to propose that TianoCore move all code review from

email

based code reviews to GitHub Pull Requests based code reviews.

The proposed date to switch would be immediately after the next

stable

tag which is currently scheduled for May 24, 2024.


O yes! Fully for it!

Does it mean edk2 only or edk2/edk2-platforms/edk2-non-osi and other
tianocore/ repositories?


I don't see why we couldn't switch all of them. Other than we need to
get all the Maintainers.txt updated with code forge usernames first.

We may want to do one at a time though.

/
      Leif


* The Pull Request submitter is required to invite the required
    maintainers and reviewers to the pull request. This is the same
    set of maintainers and reviewers that are required to be listed

in

    Cc: tags in 

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Michael Kubacki]

On 5/2/2024 12:37 PM, Kinney, Michael D wrote:




-Original Message-
From: Leif Lindholm 
Sent: Thursday, May 2, 2024 3:57 AM
To: devel@edk2.groups.io; mikub...@linux.microsoft.com; Kinney, Michael
D ; r...@edk2.groups.io
Cc: Andrew Fish (af...@apple.com) 
Subject: Re: [edk2-devel] Proposal to switch TianoCore Code Review from
email to GitHub Pull Requests on 5-24-2024

On 2024-05-02 04:08, Michael Kubacki wrote:

Thank you for this proposal. We've been anticipating this change for
years and are excited to help support it.

Here's some items we'd like to raise for feedback that we could help
implement. Many could likely be done in time for the transition.

1. Automate reviewers - We've discussed CODEOWNERS in the past.

However,

a simpler approach (in maintaining/syncing less files) would be to use
Maintainers.txt directly with a GitHub workflow since the file already
contains GitHub IDs.


That would be ideal. I know Mike worked on autogenerating CODEOWNERS
from Maintainers.txt, but ultimately the latter supports more flexible
use of wildcards (things like */AArch64/ currently requires reconciling
against the repo contents).


I have a python script that can verify if there are any differences
Between CODEOWNERS and Maintainers.txt.  I do not any tools that can
convert Maintainers.txt to CODEOWNERS.  That has been a manual process.

I recommend we identify a plan to switch to CODEOWNERS and drop
Maintainers.txt. May take a while for everyone to get used to the
differences.



I agree it would be nice to switch to CODEOWNERS to reuse the native 
functionality built into GitHub for it. We could build upon that if 
necessary.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118558): https://edk2.groups.io/g/devel/message/118558
Mute This Topic: https://groups.io/mt/105847510/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Michael Kubacki]

On 5/2/2024 6:57 AM, Leif Lindholm wrote:

On 2024-05-02 04:08, Michael Kubacki wrote:
Thank you for this proposal. We've been anticipating this change for 
years and are excited to help support it.


Here's some items we'd like to raise for feedback that we could help 
implement. Many could likely be done in time for the transition.


1. Automate reviewers - We've discussed CODEOWNERS in the past. 
However, a simpler approach (in maintaining/syncing less files) would 
be to use Maintainers.txt directly with a GitHub workflow since the 
file already contains GitHub IDs.


That would be ideal. I know Mike worked on autogenerating CODEOWNERS 
from Maintainers.txt, but ultimately the latter supports more flexible 
use of wildcards (things like */AArch64/ currently requires reconciling 
against the repo contents).


2. Make PR completion contingent on a GitHub review from at least one 
package maintainer/reviewer for each package in the PR.


Yes.

3. Dependabot is already used today to automatically create PRs when 
dependencies like pip modules have updates. To allow this to more 
effectively keep dependencies up-to-date, allow dependabot PRs to be 
completed (after normal acceptance criteria like CI and review 
requirements) without a separate human creating a duplicate PR.


I am not sure what this means in practice :)
This doesn't sound like one we need to worry about before switchover 
though.


It was a minor point to reduce extra work for keeping dependencies 
up-to-date. It will naturally lead to a PR review in the new process 
where we can discuss it further in the review.




4. Potentially warn users (with an automated comment on the PR) if 
they add a push label to a PR that is less than 24 hours old.


That sounds good.
Is there any way to prevent force-pushes within 24h of previous push?
That would make setting up a transitional review-scraper less lossy.


We can. There have been cases in the past where we need to critically 
get a change in to unblock CI for example so I didn't want to complicate 
that initially. This could serve as a reminder to those with push access 
in the meantime if we'd like.




5. Leave reminder comments on PRs with absolutely no activity after 
some agreed upon time so reviewers are notified to review the PR 
without the submitter having to watch it and send notifications.


Yes. But should take priority below 1, 2, and 4. Unless you have a 
pre-cooked thing to drop in of course.


Your priorities look good.



6. Leave reminder comments on PRs that meet all requirements to be 
completed (all reviews accounted for and status checks pass) but are 
still open so those on the PR are notified to complete it without the 
submitter having to manually watch and send reminders.


Not a response to this, but triggered by reading this:
Is there any way to approve changes within a PR on a commit by commit 
basis?


Unfortunately not. We typically resolve all conversations before giving 
an approval that would apply to all relevant commits for the given reviewer.





7. We are happy to help with process documentation.


Always appreciated,thanks.

Regards,

Leif








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118557): https://edk2.groups.io/g/devel/message/118557
Mute This Topic: https://groups.io/mt/105847510/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] StandaloneMmPkg/StandaloneMmHobLib: Remove HOB creation

[Oliver Smith-Denny]

On 5/2/2024 7:28 PM, Nhi Pham via groups.io wrote:

On 5/2/2024 4:31 AM, Oliver Smith-Denny via groups.io wrote:

Hi folks, returning to this thread because I noticed that HOB
creation still exists in StandaloneMmCore for ARM:

https://github.com/tianocore/edk2/blob/5d4c5253e8bbc0baa8837fcd868925212df85201/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/CreateHobList.c

As far as I can tell, there is only this one file that creates 6
HOBs from StandaloneMmCore. Per our earlier discussion that led to
disabling HOB creation in StandaloneMm, I think that this falls into
the case where StandaloneMm is a HOB consumer phase, not a producer
phase and so it should not be creating these HOBs. On the x64 side,
all of the StandaloneMm HOB creation functions ASSERT with the
comment that StandaloneMm is a HOB consumer phase and should not
be creating HOBs.


The HOB creation in StandaloneMmCoreEntryPoint is exclusively consumed 
by the MM_CORE_STANDALONE module 
(StandaloneMmPkg/Core/StandaloneMmCore.inf), not a MM_STANDALONE module. 
Per my understanding earlier, the MM_CORE_STANDALONE is a producer and 
other MM_STANDALONE modules are consumers. So we removed the HOB 
creation in the StandaloneMmHobLib which is consumed by MM_STANDALONE 
modules.


Also, we still retain the HOB creation in the 
StandaloneMmPkg/Library/StandaloneMmCoreHobLib library instance.




The PI spec is light on details on HOBs in Standalone MM, but it is
clear that there are HOB producer phases and HOB consumer phases.
Pre-Standalone MM, the HOB producer phase was PEI and the HOB
consumer phase was DXE/SMM. In the Standalone MM world, it still
follows that a boot phase is either a HOB consumer or a HOB
producer. Currently, Standalone MM is both, regardless that it is
the core that is producing the HOBs.

I think that Levi's work to remove HOB creation in Standalone MM
and move it to TF-A is the right move here.

Thanks,
Oliver


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118556): https://edk2.groups.io/g/devel/message/118556
Mute This Topic: https://groups.io/mt/103018869/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RESEND PATCH v4 0/5] DynamicTablesPkg: Adds FADT, HPET, WSMT and MADT Table generators

[Sami Mujawar]

Hi All,

Please find my response inline marked [SAMI].

Regards,

Sami Mujawar

On 02/05/2024, 17:36, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:


Hello Abdul,
I added some comments.
I think that:
a. patches related to HPET/WSMT should require little work
b. MADT patch needs to redefine the CmObjects it uses,
but it seems ok otherwise (just need to have the right properties
in the right objects),
c. FADT patch is re-defining CmObjects that are already existing
in ArmNameSpaceObjects.h. So there is going to be a clash with
ongoing DynamicTables objects reorganization...


I think that a. could be sent separately and should quickly go in,
b. might require a bit more checking/reviewing, and c. might need
to wait for the re-org to be finished, unless Sami thinks it's ok
to take the patch,
[SAMI] For c., I think we should not wait for the reorg to be completed. The 
FADT patch can go it the mainline if it passes the review.
The additional work would be to reorg this patch on the staging branch when 
rebasing with the edk2 mainline code. However, this can be addressed just 
before we merge the first set of reorg changes into mainline.
[/SAMI]


Regards,
Pierre




On 4/29/24 08:03, Abdul Lateef Attar wrote:
> PR: https://github.com/tianocore/edk2/pull/5500/ 
> 
> V4: delta changes
> Added X64 arch specific MADT table generator.
> V3: delta changes
> Restructure the code as the review comments.
> Added sanity check for WSMT flags.
> Added CM object for HPET base address.
> V2: delta changes
> Addressed review comments
> Adds ACPI HPET table to add HPET to ACPI namespace
> V1:
> Adds new space for ArchNameSpaceObjects.
> Adds generic FADT table generator.
> Adds generic HPET table generator.
> Adds generic WSMT table generator.
>
> Cc: Sami Mujawar mailto:sami.muja...@arm.com>>
> Cc: Pierre Gondois mailto:pierre.gond...@arm.com>>
> Cc: Abdul Lateef Attar  >
>
> Abdul Lateef Attar (5):
> DynamicTablesPkg: Adds ACPI FADT Table generator
> DynamicTablesPkg: Adds ACPI HPET Table generator
> DynamicTablesPkg: Adds ACPI WSMT Table generator
> DynamicTablesPkg: Adds ACPI SSDT HPET Table generator
> DynamicTablesPkg: Adds X64 arch MADT Table generator
>
> DynamicTablesPkg/DynamicTables.dsc.inc | 22 +-
> DynamicTablesPkg/DynamicTablesPkg.ci.yaml | 4 +-
> DynamicTablesPkg/Include/AcpiTableGenerator.h | 4 +
> .../Include/ArchNameSpaceObjects.h | 237 ++
> .../Include/ConfigurationManagerObject.h | 7 +
> .../Include/X64NameSpaceObjects.h | 48 ++
> .../Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf | 36 +
> .../Library/Acpi/AcpiFadtLib/Arm/FadtUpdate.c | 39 +
> .../Library/Acpi/AcpiFadtLib/FadtGenerator.c | 745 ++
> .../Library/Acpi/AcpiFadtLib/FadtUpdate.h | 26 +
> .../Library/Acpi/AcpiFadtLib/X64/FadtUpdate.c | 32 +
> .../Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf | 31 +
> .../Library/Acpi/AcpiHpetLib/HpetGenerator.c | 246 ++
> .../Acpi/AcpiSsdtHpetLib/AcpiSsdtHpetLib.inf | 32 +
> .../Acpi/AcpiSsdtHpetLib/SsdtHpetGenerator.c | 295 +++
> .../Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf | 30 +
> .../Library/Acpi/AcpiWsmtLib/WsmtGenerator.c | 243 ++
> .../X64/AcpiMadtLibX64/AcpiMadtLibX64.inf | 27 +
> .../Acpi/X64/AcpiMadtLibX64/MadtGenerator.c | 375 +
> 19 files changed, 2477 insertions(+), 2 deletions(-)
> create mode 100644 DynamicTablesPkg/Include/ArchNameSpaceObjects.h
> create mode 100644 DynamicTablesPkg/Include/X64NameSpaceObjects.h
> create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
> create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/Arm/FadtUpdate.c
> create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/FadtGenerator.c
> create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/FadtUpdate.h
> create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/X64/FadtUpdate.c
> create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
> create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiHpetLib/HpetGenerator.c
> create mode 100644 
> DynamicTablesPkg/Library/Acpi/AcpiSsdtHpetLib/AcpiSsdtHpetLib.inf
> create mode 100644 
> DynamicTablesPkg/Library/Acpi/AcpiSsdtHpetLib/SsdtHpetGenerator.c
> create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
> create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/WsmtGenerator.c
> create mode 100644 
> DynamicTablesPkg/Library/Acpi/X64/AcpiMadtLibX64/AcpiMadtLibX64.inf
> create mode 100644 
> DynamicTablesPkg/Library/Acpi/X64/AcpiMadtLibX64/MadtGenerator.c
>



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.