Date   

回复: 回复: [edk2-devel] Python2.7 is not working with the EDK2 build system

gaoliming
 

Cole:
Here is the error message https://edk2.groups.io/g/devel/message/80068?p=,,,20,0,0,0::recentpostdate%252Fsticky,,python,20,2,0,85296733

Yes, Python27 has been end of life. But, Edk2 has not announced to drop Python27 support. So, if someone meets with python27 issue, we need to response them.

Now, I think we can give the proposal to drop Python27 support in Edk2 project.

Thanks
Liming

-----邮件原件-----
发件人: Cole Robinson <crobinso@redhat.com>
发送时间: 2021年10月6日 0:48
收件人: gaoliming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io;
Sunny.Wang@arm.com; 'Feng, Bob C' <bob.c.feng@intel.com>; 'Chen,
Christine' <yuwei.chen@intel.com>
抄送: 'Sami Mujawar' <Sami.Mujawar@arm.com>; 'Samer El-Haj-Mahmoud'
<Samer.El-Haj-Mahmoud@arm.com>; 'Gerd Hoffmann' <kraxel@redhat.com>
主题: Re: 回复: [edk2-devel] Python2.7 is not working with the EDK2 build
system

On 9/6/21 9:18 PM, gaoliming wrote:
Bob:

Yes. Python3 is the formal support. We recommend user to use Python3.
But, if user meets the issue in Python2, user can still report the issue
in BaseTools. Its priority may be low. For this case, it is the
regression issue caused by the recent change. The patch owner is also
identified. So, I suggest the patch owner to follow up and enhance his
patch.
Sorry for the delayed response, I was on paternity leave since August.

I haven't seen the actual error in this thread. Is there a clear python
error being thrown? Maybe the fix is simple but I can't

But as mentioned elsewhere, python2 has been End of Life since Jan 1
2020, over 1.5 years ago. It's going to become increasingly difficult to
keep code working on python2 and latest python3.

- Cole


回复: [edk2-devel] [PATCH v7 1/1] MdePkg/BaseLib: Add QuickSort function on BaseLib

gaoliming
 

Kuo:
I suggest to move SORT_COMPARE definition from
MdeModulePkg\Include\Library\SortLib.h to MdePkg\Include\Library\BaseLib.h,
and then let SortLib.h include BaseLib.h.

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 IanX Kuo
发送时间: 2021年10月8日 8:27
收件人: devel@edk2.groups.io
抄送: amy.chan@intel.com; ray.ni@intel.com; IanX Kuo
<ianx.kuo@intel.com>; Michael D Kinney <michael.d.kinney@intel.com>;
Liming Gao <gaoliming@byosoft.com.cn>; Zhiguang Liu
<zhiguang.liu@intel.com>
主题: [edk2-devel] [PATCH v7 1/1] MdePkg/BaseLib: Add QuickSort function
on BaseLib

From: IanX Kuo <ianx.kuo@intel.com>

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3675

Add QuickSort function into BaseLib

Cc: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: IanX Kuo <ianx.kuo@intel.com>
---
MdePkg/Include/Library/BaseLib.h | 49 ++++++++
MdePkg/Library/BaseLib/BaseLib.inf | 1 +
MdePkg/Library/BaseLib/QuickSort.c | 116
++++++++++++++++++
.../Library/BaseLib/UnitTestHostBaseLib.inf | 3 +-
4 files changed, 168 insertions(+), 1 deletion(-)
create mode 100644 MdePkg/Library/BaseLib/QuickSort.c

diff --git a/MdePkg/Include/Library/BaseLib.h
b/MdePkg/Include/Library/BaseLib.h
index 2452c1d92e..0ae0f4e6af 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -2856,6 +2856,55 @@ RemoveEntryList (
//

// Math Services

//

+/**

+ Prototype for comparison function for any two element types.

+

+ @param[in] Buffer1 The pointer to first buffer.

+ @param[in] Buffer2 The pointer to second buffer.

+

+ @retval 0 Buffer1 equal to Buffer2.

+ @return <0 Buffer1 is less than Buffer2.

+ @return >0 Buffer1 is greater than
Buffer2.

+**/

+typedef

+INTN

+(EFIAPI *BASE_SORT_COMPARE)(

+ IN CONST VOID *Buffer1,

+ IN CONST VOID *Buffer2

+ );

+

+/**

+ This function is identical to perform QuickSort,

+ except that is uses the pre-allocated buffer so the in place sorting
does not
need to

+ allocate and free buffers constantly.

+

+ Each element must be equal sized.

+

+ if BufferToSort is NULL, then ASSERT.

+ if CompareFunction is NULL, then ASSERT.

+ if BufferOneElement is NULL, then ASSERT.

+ if ElementSize is < 1, then ASSERT.

+

+ if Count is < 2 then perform no action.

+

+ @param[in, out] BufferToSort on call a Buffer of (possibly sorted)
elements

+ on return a buffer of sorted
elements

+ @param[in] Count the number of elements in the
buffer to sort

+ @param[in] ElementSize Size of an element in bytes

+ @param[in] CompareFunction The function to call to perform the
comparison

+ of any 2 elements

+ @param[out] BufferOneElement Caller provided buffer whose size
equals to ElementSize.

+ It's used by QuickSort() for
swapping in sorting.

+**/

+VOID

+EFIAPI

+QuickSort (

+ IN OUT VOID *BufferToSort,

+ IN CONST UINTN Count,

+ IN CONST UINTN ElementSize,

+ IN BASE_SORT_COMPARE CompareFunction,

+ OUT VOID *BufferOneElement

+ );



/**

Shifts a 64-bit integer left between 0 and 63 bits. The low bits are
filled

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf
b/MdePkg/Library/BaseLib/BaseLib.inf
index 6efa5315b6..cebda3b210 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -32,6 +32,7 @@
SwapBytes16.c

LongJump.c

SetJump.c

+ QuickSort.c

RShiftU64.c

RRotU64.c

RRotU32.c

diff --git a/MdePkg/Library/BaseLib/QuickSort.c
b/MdePkg/Library/BaseLib/QuickSort.c
new file mode 100644
index 0000000000..a825c072b0
--- /dev/null
+++ b/MdePkg/Library/BaseLib/QuickSort.c
@@ -0,0 +1,116 @@
+/** @file

+ Math worker functions.

+

+ Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>

+ SPDX-License-Identifier: BSD-2-Clause-Patent

+

+**/

+

+#include "BaseLibInternals.h"

+

+/**

+ This function is identical to perform QuickSort,

+ except that is uses the pre-allocated buffer so the in place sorting
does not
need to

+ allocate and free buffers constantly.

+

+ Each element must be equal sized.

+

+ if BufferToSort is NULL, then ASSERT.

+ if CompareFunction is NULL, then ASSERT.

+ if BufferOneElement is NULL, then ASSERT.

+ if ElementSize is < 1, then ASSERT.

+

+ if Count is < 2 then perform no action.

+

+ @param[in, out] BufferToSort on call a Buffer of (possibly sorted)
elements

+ on return a buffer of sorted
elements

+ @param[in] Count the number of elements in the
buffer to sort

+ @param[in] ElementSize Size of an element in bytes

+ @param[in] CompareFunction The function to call to perform the
comparison

+ of any 2 elements

+ @param[out] BufferOneElement Caller provided buffer whose size
equals to ElementSize.

+ It's used by QuickSort() for
swapping in sorting.

+**/

+VOID

+EFIAPI

+QuickSort (

+ IN OUT VOID *BufferToSort,

+ IN CONST UINTN Count,

+ IN CONST UINTN ElementSize,

+ IN BASE_SORT_COMPARE CompareFunction,

+ OUT VOID *BufferOneElement

+ )

+{

+ VOID *Pivot;

+ UINTN LoopCount;

+ UINTN NextSwapLocation;

+

+ ASSERT (BufferToSort != NULL);

+ ASSERT (CompareFunction != NULL);

+ ASSERT (BufferOneElement != NULL);

+ ASSERT (ElementSize >= 1);

+

+ if (Count < 2) {

+ return;

+ }

+

+ NextSwapLocation = 0;

+

+ //

+ // pick a pivot (we choose last element)

+ //

+ Pivot = ((UINT8*) BufferToSort + ((Count - 1) * ElementSize));

+

+ //

+ // Now get the pivot such that all on "left" are below it

+ // and everything "right" are above it

+ //

+ for (LoopCount = 0; LoopCount < Count -1; LoopCount++) {

+ //

+ // if the element is less than or equal to the pivot

+ //

+ if (CompareFunction ((VOID*) ((UINT8*) BufferToSort + ((LoopCount) *
ElementSize)), Pivot) <= 0){

+ //

+ // swap

+ //

+ CopyMem (BufferOneElement, (UINT8*) BufferToSort +
(NextSwapLocation * ElementSize), ElementSize);

+ CopyMem ((UINT8*) BufferToSort + (NextSwapLocation *
ElementSize), (UINT8*) BufferToSort + ((LoopCount) * ElementSize),
ElementSize);

+ CopyMem ((UINT8*) BufferToSort + ((LoopCount)*ElementSize),
BufferOneElement, ElementSize);

+

+ //

+ // increment NextSwapLocation

+ //

+ NextSwapLocation++;

+ }

+ }

+ //

+ // swap pivot to it's final position (NextSwapLocation)

+ //

+ CopyMem (BufferOneElement, Pivot, ElementSize);

+ CopyMem (Pivot, (UINT8*) BufferToSort + (NextSwapLocation *
ElementSize), ElementSize);

+ CopyMem ((UINT8*) BufferToSort + (NextSwapLocation * ElementSize),
BufferOneElement, ElementSize);

+

+ //

+ // Now recurse on 2 partial lists. neither of these will have the
'pivot'
element

+ // IE list is sorted left half, pivot element, sorted right half...

+ //

+ if (NextSwapLocation >= 2) {

+ QuickSort (

+ BufferToSort,

+ NextSwapLocation,

+ ElementSize,

+ CompareFunction,

+ BufferOneElement

+ );

+ }

+

+ if ((Count - NextSwapLocation - 1) >= 2) {

+ QuickSort (

+ (UINT8 *)BufferToSort + (NextSwapLocation + 1) * ElementSize,

+ Count - NextSwapLocation - 1,

+ ElementSize,

+ CompareFunction,

+ BufferOneElement

+ );

+ }

+}

diff --git a/MdePkg/Library/BaseLib/UnitTestHostBaseLib.inf
b/MdePkg/Library/BaseLib/UnitTestHostBaseLib.inf
index eae1a7158d..d09bd12bef 100644
--- a/MdePkg/Library/BaseLib/UnitTestHostBaseLib.inf
+++ b/MdePkg/Library/BaseLib/UnitTestHostBaseLib.inf
@@ -1,7 +1,7 @@
## @file

# Base Library implementation for use with host based unit tests.

#

-# Copyright (c) 2007 - 2020, Intel Corporation. All rights reserved.<BR>

+# Copyright (c) 2007 - 2021, Intel Corporation. All rights reserved.<BR>

# Portions copyright (c) 2008 - 2009, Apple Inc. All rights
reserved.<BR>

# Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.<BR>

# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All
rights reserved.<BR>

@@ -33,6 +33,7 @@
SwapBytes16.c

LongJump.c

SetJump.c

+ QuickSort.c

RShiftU64.c

RRotU64.c

RRotU32.c

--
2.30.0.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81615): https://edk2.groups.io/g/devel/message/81615
Mute This Topic: https://groups.io/mt/86159728/4905953
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub
[gaoliming@byosoft.com.cn]
-=-=-=-=-=-=


Event: TianoCore Community Meeting - APAC/NAMO - 10/07/2021 #cal-reminder

devel@edk2.groups.io Calendar <noreply@...>
 

Reminder: TianoCore Community Meeting - APAC/NAMO

When:
10/07/2021
7:30pm to 8:30pm
(UTC-07:00) America/Los Angeles

Where:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZWNiZWM1MzgtNWEzMy00MTgwLTgwNjAtNWQ1ZWUwZmQzNjVh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d

Organizer: Soumya Guptha

View Event

Description:

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 119 132 712 6

Alternate VTC dialing instructions

Or call in (audio only)

+1 916-245-6934,,494156131#   United States, Sacramento

Phone Conference ID: 494 156 131#

Find a local number | Reset PIN

Learn More | Meeting options


回复: [edk2-devel] [PATCH v1 1/1] MdePkg: Fix ACPI memory aggregator/device type mismatch

gaoliming
 

Samer:
Thanks for your information. I agree this change. Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>

Thanks
Liming

-----邮件原件-----
发件人: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
发送时间: 2021年10月8日 9:45
收件人: devel@edk2.groups.io; gaoliming@byosoft.com.cn; Christopher
Jones <Christopher.Jones@arm.com>
抄送: michael.d.kinney@intel.com; zhiguang.liu@intel.com; Sami Mujawar
<Sami.Mujawar@arm.com>; Ben Adderson <Ben.Adderson@arm.com>;
Akanksha Jain <Akanksha.Jain2@arm.com>; Matteo Carlini
<Matteo.Carlini@arm.com>; nd <nd@arm.com>; Samer El-Haj-Mahmoud
<Samer.El-Haj-Mahmoud@arm.com>
主题: RE: [edk2-devel] [PATCH v1 1/1] MdePkg: Fix ACPI memory
aggregator/device type mismatch

We did investigate this in the BZ, and the conclusion was it is safer to update
the code to match the spec. The only OS implementation we have seen so far
is in Linux, and it uses the spec defined values (although for limited usage).
See https://bugzilla.tianocore.org/show_bug.cgi?id=3579




-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
gaoliming via groups.io
Sent: Thursday, October 7, 2021 9:26 PM
To: devel@edk2.groups.io; Christopher Jones
<Christopher.Jones@arm.com>
Cc: michael.d.kinney@intel.com; zhiguang.liu@intel.com; Sami Mujawar
<Sami.Mujawar@arm.com>; Ben Adderson <Ben.Adderson@arm.com>;
Akanksha Jain <Akanksha.Jain2@arm.com>; Matteo Carlini
<Matteo.Carlini@arm.com>; nd <nd@arm.com>
Subject: 回复: [edk2-devel] [PATCH v1 1/1] MdePkg: Fix ACPI memory
aggregator/device type mismatch

Jones:
Do you know what impact will be introduced by this change?

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Chris
Jones
发送时间: 2021年10月6日 18:12
收件人: devel@edk2.groups.io
抄送: michael.d.kinney@intel.com; gaoliming@byosoft.com.cn;
zhiguang.liu@intel.com; Sami.Mujawar@arm.com;
Ben.Adderson@arm.com;
Akanksha.Jain2@arm.com; Matteo.Carlini@arm.com; nd@arm.com
主题: [edk2-devel] [PATCH v1 1/1] MdePkg: Fix ACPI memory
aggregator/device type mismatch

Bugzilla: 3578 (https://bugzilla.tianocore.org/show_bug.cgi?id=3579)

Since the Common Memory Device (formerly Memory Aggregator Device)
was
introduced in ACPI 5.0, the edk2 type values have not matched the
values defined in the ACPI specification.

Fix this discrepancy by aligning the code to match the specification.

Signed-off-by: Chris Jones <christopher.jones@arm.com>
---
MdePkg/Include/IndustryStandard/Acpi50.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi51.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi60.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi61.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi62.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi63.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi64.h | 6 +++---
7 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Acpi50.h
b/MdePkg/Include/IndustryStandard/Acpi50.h
index
31a47e6a2c4276d5b1ad7b834af84844090b64c5..83d787c7650cf649fe3d2e1
2e7983bae86a2a114 100644
--- a/MdePkg/Include/IndustryStandard/Acpi50.h
+++ b/MdePkg/Include/IndustryStandard/Acpi50.h
@@ -996,9 +996,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi51.h
b/MdePkg/Include/IndustryStandard/Acpi51.h
index
fc28ffa18fc6a22e52fda88fade6ad80b2817cc3..5fbf7c99f1f7d6ca9109f198bd
3f25f12bd47961 100644
--- a/MdePkg/Include/IndustryStandard/Acpi51.h
+++ b/MdePkg/Include/IndustryStandard/Acpi51.h
@@ -951,9 +951,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi60.h
b/MdePkg/Include/IndustryStandard/Acpi60.h
index
5dcd73b6f1ec4bccc7fdae7d56c2963ab58764f9..eba4248e1d5733d21973f0d
ac2286e02238a0aae 100644
--- a/MdePkg/Include/IndustryStandard/Acpi60.h
+++ b/MdePkg/Include/IndustryStandard/Acpi60.h
@@ -966,9 +966,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi61.h
b/MdePkg/Include/IndustryStandard/Acpi61.h
index
8626833a794dfb4a6f19d459d5214c6caefdbbee..7a776020baa8f3ee7b6f05fe
e336225ab6589ce0 100644
--- a/MdePkg/Include/IndustryStandard/Acpi61.h
+++ b/MdePkg/Include/IndustryStandard/Acpi61.h
@@ -966,9 +966,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi62.h
b/MdePkg/Include/IndustryStandard/Acpi62.h
index
1b2704e98e3703a4405075247432ec842e45021b..33a0a0f21959df8b64803e
972ab19f0c0ab1619e 100644
--- a/MdePkg/Include/IndustryStandard/Acpi62.h
+++ b/MdePkg/Include/IndustryStandard/Acpi62.h
@@ -1078,9 +1078,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi63.h
b/MdePkg/Include/IndustryStandard/Acpi63.h
index
b281b30155e90eba5169dc39bde9a3379e3b7005..3b1426af27ea4ebada1a1
2e99ce958bb288ad931 100644
--- a/MdePkg/Include/IndustryStandard/Acpi63.h
+++ b/MdePkg/Include/IndustryStandard/Acpi63.h
@@ -1040,9 +1040,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi64.h
b/MdePkg/Include/IndustryStandard/Acpi64.h
index
3a91302f8c0e71d4951d27aac35322073219c836..8346d83f1249045497b602
907b94fbb2b495cd56 100644
--- a/MdePkg/Include/IndustryStandard/Acpi64.h
+++ b/MdePkg/Include/IndustryStandard/Acpi64.h
@@ -1075,9 +1075,9 @@ typedef struct {
///
/// Memory Device Type.
///
-#define EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_MEMORY_CONTROLLER
0x2
-#define EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_DIMM
0x3
+#define EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_MEMORY_CONTROLLER
0x1
+#define EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_DIMM
0x2
#define
EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_VENDOR_SPECIFIC_TYPE
0xFF

///
--
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")










Re: [PATCH v1 1/1] MdePkg: Fix ACPI memory aggregator/device type mismatch

Samer El-Haj-Mahmoud
 

We did investigate this in the BZ, and the conclusion was it is safer to update the code to match the spec. The only OS implementation we have seen so far is in Linux, and it uses the spec defined values (although for limited usage). See https://bugzilla.tianocore.org/show_bug.cgi?id=3579

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
gaoliming via groups.io
Sent: Thursday, October 7, 2021 9:26 PM
To: devel@edk2.groups.io; Christopher Jones
<Christopher.Jones@arm.com>
Cc: michael.d.kinney@intel.com; zhiguang.liu@intel.com; Sami Mujawar
<Sami.Mujawar@arm.com>; Ben Adderson <Ben.Adderson@arm.com>;
Akanksha Jain <Akanksha.Jain2@arm.com>; Matteo Carlini
<Matteo.Carlini@arm.com>; nd <nd@arm.com>
Subject: 回复: [edk2-devel] [PATCH v1 1/1] MdePkg: Fix ACPI memory
aggregator/device type mismatch

Jones:
Do you know what impact will be introduced by this change?

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Chris Jones
发送时间: 2021年10月6日 18:12
收件人: devel@edk2.groups.io
抄送: michael.d.kinney@intel.com; gaoliming@byosoft.com.cn;
zhiguang.liu@intel.com; Sami.Mujawar@arm.com;
Ben.Adderson@arm.com;
Akanksha.Jain2@arm.com; Matteo.Carlini@arm.com; nd@arm.com
主题: [edk2-devel] [PATCH v1 1/1] MdePkg: Fix ACPI memory
aggregator/device type mismatch

Bugzilla: 3578 (https://bugzilla.tianocore.org/show_bug.cgi?id=3579)

Since the Common Memory Device (formerly Memory Aggregator Device)
was
introduced in ACPI 5.0, the edk2 type values have not matched the
values defined in the ACPI specification.

Fix this discrepancy by aligning the code to match the specification.

Signed-off-by: Chris Jones <christopher.jones@arm.com>
---
MdePkg/Include/IndustryStandard/Acpi50.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi51.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi60.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi61.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi62.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi63.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi64.h | 6 +++---
7 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Acpi50.h
b/MdePkg/Include/IndustryStandard/Acpi50.h
index
31a47e6a2c4276d5b1ad7b834af84844090b64c5..83d787c7650cf649fe3d2e1
2e7983bae86a2a114 100644
--- a/MdePkg/Include/IndustryStandard/Acpi50.h
+++ b/MdePkg/Include/IndustryStandard/Acpi50.h
@@ -996,9 +996,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi51.h
b/MdePkg/Include/IndustryStandard/Acpi51.h
index
fc28ffa18fc6a22e52fda88fade6ad80b2817cc3..5fbf7c99f1f7d6ca9109f198bd
3f25f12bd47961 100644
--- a/MdePkg/Include/IndustryStandard/Acpi51.h
+++ b/MdePkg/Include/IndustryStandard/Acpi51.h
@@ -951,9 +951,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi60.h
b/MdePkg/Include/IndustryStandard/Acpi60.h
index
5dcd73b6f1ec4bccc7fdae7d56c2963ab58764f9..eba4248e1d5733d21973f0d
ac2286e02238a0aae 100644
--- a/MdePkg/Include/IndustryStandard/Acpi60.h
+++ b/MdePkg/Include/IndustryStandard/Acpi60.h
@@ -966,9 +966,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi61.h
b/MdePkg/Include/IndustryStandard/Acpi61.h
index
8626833a794dfb4a6f19d459d5214c6caefdbbee..7a776020baa8f3ee7b6f05fe
e336225ab6589ce0 100644
--- a/MdePkg/Include/IndustryStandard/Acpi61.h
+++ b/MdePkg/Include/IndustryStandard/Acpi61.h
@@ -966,9 +966,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi62.h
b/MdePkg/Include/IndustryStandard/Acpi62.h
index
1b2704e98e3703a4405075247432ec842e45021b..33a0a0f21959df8b64803e
972ab19f0c0ab1619e 100644
--- a/MdePkg/Include/IndustryStandard/Acpi62.h
+++ b/MdePkg/Include/IndustryStandard/Acpi62.h
@@ -1078,9 +1078,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi63.h
b/MdePkg/Include/IndustryStandard/Acpi63.h
index
b281b30155e90eba5169dc39bde9a3379e3b7005..3b1426af27ea4ebada1a1
2e99ce958bb288ad931 100644
--- a/MdePkg/Include/IndustryStandard/Acpi63.h
+++ b/MdePkg/Include/IndustryStandard/Acpi63.h
@@ -1040,9 +1040,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi64.h
b/MdePkg/Include/IndustryStandard/Acpi64.h
index
3a91302f8c0e71d4951d27aac35322073219c836..8346d83f1249045497b602
907b94fbb2b495cd56 100644
--- a/MdePkg/Include/IndustryStandard/Acpi64.h
+++ b/MdePkg/Include/IndustryStandard/Acpi64.h
@@ -1075,9 +1075,9 @@ typedef struct {
///
/// Memory Device Type.
///
-#define EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_MEMORY_CONTROLLER
0x2
-#define EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_DIMM
0x3
+#define EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_MEMORY_CONTROLLER
0x1
+#define EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_DIMM
0x2
#define
EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_VENDOR_SPECIFIC_TYPE
0xFF

///
--
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")










Re: [PATCH] UserAuthFeaturePkg/UserAuthenticationDxeSmm: The SMI to handle the user authentication should be unregister before booting to OS

Dandan Bi
 

Reviewed-by: Dandan Bi <dandan.bi@intel.com>



Thanks,
Dandan

-----Original Message-----
From: Shi, Hao <hao.shi@intel.com>
Sent: Tuesday, September 28, 2021 10:09 AM
To: devel@edk2.groups.io
Cc: Shi, Hao <hao.shi@intel.com>; Bi, Dandan <dandan.bi@intel.com>;
Liming Gao <gaoliming@byosoft.com.cn>
Subject: [PATCH] UserAuthFeaturePkg/UserAuthenticationDxeSmm: The
SMI to handle the user authentication should be unregister before booting
to OS

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3648

Register SmmExitBootServices and SmmLegacyBoot callback function to
unregister this handler.

Signed-off-by: Hao Shi <hao.shi@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
---
.../UserAuthenticationSmm.c | 39 +++++++++++++++++--
.../UserAuthenticationSmm.inf | 2 +
2 files changed, 38 insertions(+), 3 deletions(-)

diff --git
a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDx
eSmm/UserAuthenticationSmm.c
b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDx
eSmm/UserAuthenticationSmm.c
index 07e834eb..3d66010b 100644
---
a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDx
eSmm/UserAuthenticationSmm.c
+++
b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthentication
+++ DxeSmm/UserAuthenticationSmm.c
@@ -13,6 +13,7 @@ UINTN mAdminPasswordTryCount = 0;

BOOLEAN mNeedReVerify = TRUE;
BOOLEAN mPasswordVerified = FALSE;
+EFI_HANDLE mSmmHandle = NULL;

/**
Verify if the password is correct.
@@ -612,6 +613,30 @@ EXIT:
return EFI_SUCCESS;
}

+/**
+ Performs Exit Boot Services UserAuthentication actions
+
+ @param[in] Protocol Points to the protocol's unique identifier.
+ @param[in] Interface Points to the interface instance.
+ @param[in] Handle The handle on which the interface was installed.
+
+ @retval EFI_SUCCESS Notification runs successfully.
+**/
+EFI_STATUS
+EFIAPI
+UaExitBootServices (
+ IN CONST EFI_GUID *Protocol,
+ IN VOID *Interface,
+ IN EFI_HANDLE Handle
+ )
+{
+ DEBUG ((DEBUG_INFO, "Unregister User Authentication Smi\n"));
+
+ gSmst->SmiHandlerUnRegister(mSmmHandle);
+
+ return EFI_SUCCESS;
+}
+
/**
Main entry for this driver.

@@ -629,10 +654,11 @@ PasswordSmmInit (
)
{
EFI_STATUS Status;
- EFI_HANDLE SmmHandle;
EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;
CHAR16
PasswordHistoryName[sizeof(USER_AUTHENTICATION_VAR_NAME)/sizeof(
CHAR16) + 5];
UINTN Index;
+ EFI_EVENT ExitBootServicesEvent;
+ EFI_EVENT LegacyBootEvent;

ASSERT (PASSWORD_HASH_SIZE == SHA256_DIGEST_SIZE);
ASSERT (PASSWORD_HISTORY_CHECK_COUNT < 0xFFFF); @@ -657,13
+683,20 @@ PasswordSmmInit (
ASSERT_EFI_ERROR (Status);
}

- SmmHandle = NULL;
- Status = gSmst->SmiHandlerRegister (SmmPasswordHandler,
&gUserAuthenticationGuid, &SmmHandle);
+ Status = gSmst->SmiHandlerRegister (SmmPasswordHandler,
+ &gUserAuthenticationGuid, &mSmmHandle);
ASSERT_EFI_ERROR (Status);
if (EFI_ERROR (Status)) {
return Status;
}

+ //
+ // Register for SmmExitBootServices and SmmLegacyBoot notification.
+ //
+ Status = gSmst->SmmRegisterProtocolNotify
+ (&gEdkiiSmmExitBootServicesProtocolGuid, UaExitBootServices,
+ &ExitBootServicesEvent); ASSERT_EFI_ERROR (Status); Status =
+ gSmst->SmmRegisterProtocolNotify (&gEdkiiSmmLegacyBootProtocolGuid,
+ UaExitBootServices, &LegacyBootEvent); ASSERT_EFI_ERROR (Status);
+
if (IsPasswordCleared()) {
DEBUG ((DEBUG_INFO, "IsPasswordCleared\n"));
SavePasswordToVariable (&gUserAuthenticationGuid, NULL, 0); diff --git
a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDx
eSmm/UserAuthenticationSmm.inf
b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDx
eSmm/UserAuthenticationSmm.inf
index 0b33b194..d73a2fe2 100644
---
a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDx
eSmm/UserAuthenticationSmm.inf
+++
b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthentication
+++ DxeSmm/UserAuthenticationSmm.inf
@@ -48,6 +48,8 @@
[Protocols]
gEdkiiVariableLockProtocolGuid ## CONSUMES
gEfiSmmVariableProtocolGuid ## CONSUMES
+ gEdkiiSmmExitBootServicesProtocolGuid ## CONSUMES
+ gEdkiiSmmLegacyBootProtocolGuid ## CONSUMES

[Depex]
gEfiSmmVariableProtocolGuid AND gEfiVariableWriteArchProtocolGuid
--
2.31.1.windows.1


Re: [PATCH] MdeModulePkg/Core/Dxe: Add lock protection in CoreLocateHandleBuffer()

Dandan Bi
 

Reviewed-by: Dandan Bi <dandan.bi@intel.com>



Thanks,
Dandan

-----Original Message-----
From: Ma, Hua <hua.ma@intel.com>
Sent: Wednesday, September 29, 2021 1:49 PM
To: devel@edk2.groups.io
Cc: Ma, Hua <hua.ma@intel.com>; Wang, Jian J <jian.j.wang@intel.com>;
Liming Gao <gaoliming@byosoft.com.cn>; Bi, Dandan <dandan.bi@intel.com>
Subject: [PATCH] MdeModulePkg/Core/Dxe: Add lock protection in
CoreLocateHandleBuffer()

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3666

Currently, CoreLocateHandleBuffer() follows three steps:
1) get the size of protocol database firstly
2) allocate the buffer based on the size
3) get the protocol database into the buffer There is no lock protection for
the whole three steps. If a new protocol added in step 2) by other task, e.g.
(event timer handle USB device hotplug). The size of protocol database may
be increased and cannot fit into the previous buffer in step 3). The protocol
database cannot be returned successfully, EFI_BUFFER_TOO_SMALL error
will be returned.

This patch adds the lock to protect the whole three steps.
It can make sure the correct protocol database be returned.

Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Hua Ma <hua.ma@intel.com>
---
MdeModulePkg/Core/Dxe/Hand/Locate.c | 64
+++++++++++++++++++++++------
1 file changed, 51 insertions(+), 13 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Hand/Locate.c
b/MdeModulePkg/Core/Dxe/Hand/Locate.c
index be17f4cbc3..4987c046c6 100644
--- a/MdeModulePkg/Core/Dxe/Hand/Locate.c
+++ b/MdeModulePkg/Core/Dxe/Hand/Locate.c
@@ -86,7 +86,8 @@ CoreGetNextLocateByProtocol (


/**
- Locates the requested handle(s) and returns them in Buffer.
+ Internal function for locating the requested handle(s) and returns them in
Buffer.
+ The caller should already have acquired the ProtocolLock.

@param SearchType The type of search to perform to locate the
handles @@ -104,8 +105,7 @@
CoreGetNextLocateByProtocol (

**/
EFI_STATUS
-EFIAPI
-CoreLocateHandle (
+InternalCoreLocateHandle (
IN EFI_LOCATE_SEARCH_TYPE SearchType,
IN EFI_GUID *Protocol OPTIONAL,
IN VOID *SearchKey OPTIONAL,
@@ -143,11 +143,6 @@ CoreLocateHandle (
ResultBuffer = (IHANDLE **) Buffer;
Status = EFI_SUCCESS;

- //
- // Lock the protocol database
- //
- CoreAcquireProtocolLock ();
-
//
// Get the search function based on type
//
@@ -190,7 +185,6 @@ CoreLocateHandle (
}

if (EFI_ERROR(Status)) {
- CoreReleaseProtocolLock ();
return Status;
}

@@ -247,10 +241,47 @@ CoreLocateHandle (
}
}

- CoreReleaseProtocolLock ();
return Status;
}

+/**
+ Locates the requested handle(s) and returns them in Buffer.
+
+ @param SearchType The type of search to perform to locate the
+ handles
+ @param Protocol The protocol to search for
+ @param SearchKey Dependant on SearchType
+ @param BufferSize On input the size of Buffer. On output the
+ size of data returned.
+ @param Buffer The buffer to return the results in
+
+ @retval EFI_BUFFER_TOO_SMALL Buffer too small, required buffer size is
+ returned in BufferSize.
+ @retval EFI_INVALID_PARAMETER Invalid parameter
+ @retval EFI_SUCCESS Successfully found the requested handle(s)
and
+ returns them in Buffer.
+
+**/
+EFI_STATUS
+EFIAPI
+CoreLocateHandle (
+ IN EFI_LOCATE_SEARCH_TYPE SearchType,
+ IN EFI_GUID *Protocol OPTIONAL,
+ IN VOID *SearchKey OPTIONAL,
+ IN OUT UINTN *BufferSize,
+ OUT EFI_HANDLE *Buffer
+ )
+{
+ EFI_STATUS Status;
+
+ //
+ // Lock the protocol database
+ //
+ CoreAcquireProtocolLock ();
+ Status = InternalCoreLocateHandle(SearchType, Protocol, SearchKey,
+BufferSize, Buffer);
+ CoreReleaseProtocolLock ();
+ return Status;
+}


/**
@@ -610,7 +641,6 @@ Done:
return Status;
}

-
/**
Function returns an array of handles that support the requested protocol
in a buffer allocated from pool. This is a version of CoreLocateHandle() @@
-657,7 +687,12 @@ CoreLocateHandleBuffer (
BufferSize = 0;
*NumberHandles = 0;
*Buffer = NULL;
- Status = CoreLocateHandle (
+
+ //
+ // Lock the protocol database
+ //
+ CoreAcquireProtocolLock();
+ Status = InternalCoreLocateHandle (
SearchType,
Protocol,
SearchKey,
@@ -674,15 +709,17 @@ CoreLocateHandleBuffer (
if (Status != EFI_INVALID_PARAMETER) {
Status = EFI_NOT_FOUND;
}
+ CoreReleaseProtocolLock ();
return Status;
}

*Buffer = AllocatePool (BufferSize);
if (*Buffer == NULL) {
+ CoreReleaseProtocolLock ();
return EFI_OUT_OF_RESOURCES;
}

- Status = CoreLocateHandle (
+ Status = InternalCoreLocateHandle (
SearchType,
Protocol,
SearchKey,
@@ -695,6 +732,7 @@ CoreLocateHandleBuffer (
*NumberHandles = 0;
}

+ CoreReleaseProtocolLock ();
return Status;
}

--
2.32.0.windows.2


回复: [edk2-devel] [PATCH v1 1/1] MdePkg: Fix ACPI memory aggregator/device type mismatch

gaoliming
 

Jones:
Do you know what impact will be introduced by this change?

Thanks
Liming

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Chris Jones
发送时间: 2021年10月6日 18:12
收件人: devel@edk2.groups.io
抄送: michael.d.kinney@intel.com; gaoliming@byosoft.com.cn;
zhiguang.liu@intel.com; Sami.Mujawar@arm.com; Ben.Adderson@arm.com;
Akanksha.Jain2@arm.com; Matteo.Carlini@arm.com; nd@arm.com
主题: [edk2-devel] [PATCH v1 1/1] MdePkg: Fix ACPI memory
aggregator/device type mismatch

Bugzilla: 3578 (https://bugzilla.tianocore.org/show_bug.cgi?id=3579)

Since the Common Memory Device (formerly Memory Aggregator Device)
was
introduced in ACPI 5.0, the edk2 type values have not matched the
values defined in the ACPI specification.

Fix this discrepancy by aligning the code to match the specification.

Signed-off-by: Chris Jones <christopher.jones@arm.com>
---
MdePkg/Include/IndustryStandard/Acpi50.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi51.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi60.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi61.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi62.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi63.h | 6 +++---
MdePkg/Include/IndustryStandard/Acpi64.h | 6 +++---
7 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Acpi50.h
b/MdePkg/Include/IndustryStandard/Acpi50.h
index
31a47e6a2c4276d5b1ad7b834af84844090b64c5..83d787c7650cf649fe3d2e1
2e7983bae86a2a114 100644
--- a/MdePkg/Include/IndustryStandard/Acpi50.h
+++ b/MdePkg/Include/IndustryStandard/Acpi50.h
@@ -996,9 +996,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi51.h
b/MdePkg/Include/IndustryStandard/Acpi51.h
index
fc28ffa18fc6a22e52fda88fade6ad80b2817cc3..5fbf7c99f1f7d6ca9109f198bd
3f25f12bd47961 100644
--- a/MdePkg/Include/IndustryStandard/Acpi51.h
+++ b/MdePkg/Include/IndustryStandard/Acpi51.h
@@ -951,9 +951,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi60.h
b/MdePkg/Include/IndustryStandard/Acpi60.h
index
5dcd73b6f1ec4bccc7fdae7d56c2963ab58764f9..eba4248e1d5733d21973f0d
ac2286e02238a0aae 100644
--- a/MdePkg/Include/IndustryStandard/Acpi60.h
+++ b/MdePkg/Include/IndustryStandard/Acpi60.h
@@ -966,9 +966,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi61.h
b/MdePkg/Include/IndustryStandard/Acpi61.h
index
8626833a794dfb4a6f19d459d5214c6caefdbbee..7a776020baa8f3ee7b6f05fe
e336225ab6589ce0 100644
--- a/MdePkg/Include/IndustryStandard/Acpi61.h
+++ b/MdePkg/Include/IndustryStandard/Acpi61.h
@@ -966,9 +966,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_6_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi62.h
b/MdePkg/Include/IndustryStandard/Acpi62.h
index
1b2704e98e3703a4405075247432ec842e45021b..33a0a0f21959df8b64803e
972ab19f0c0ab1619e 100644
--- a/MdePkg/Include/IndustryStandard/Acpi62.h
+++ b/MdePkg/Include/IndustryStandard/Acpi62.h
@@ -1078,9 +1078,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_6_2_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi63.h
b/MdePkg/Include/IndustryStandard/Acpi63.h
index
b281b30155e90eba5169dc39bde9a3379e3b7005..3b1426af27ea4ebada1a1
2e99ce958bb288ad931 100644
--- a/MdePkg/Include/IndustryStandard/Acpi63.h
+++ b/MdePkg/Include/IndustryStandard/Acpi63.h
@@ -1040,9 +1040,9 @@ typedef struct {
///
/// Memory Aggregator Device Type
///
-#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x2
-#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x3
+#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
ONTROLLER 0x1
+#define
EFI_ACPI_6_3_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
0x2

///
/// Socket Memory Aggregator Device Structure.
diff --git a/MdePkg/Include/IndustryStandard/Acpi64.h
b/MdePkg/Include/IndustryStandard/Acpi64.h
index
3a91302f8c0e71d4951d27aac35322073219c836..8346d83f1249045497b602
907b94fbb2b495cd56 100644
--- a/MdePkg/Include/IndustryStandard/Acpi64.h
+++ b/MdePkg/Include/IndustryStandard/Acpi64.h
@@ -1075,9 +1075,9 @@ typedef struct {
///
/// Memory Device Type.
///
-#define EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_SOCKET
0x1
-#define
EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_MEMORY_CONTROLLER
0x2
-#define EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_DIMM
0x3
+#define EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_SOCKET
0x0
+#define
EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_MEMORY_CONTROLLER
0x1
+#define EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_DIMM
0x2
#define
EFI_ACPI_6_4_PMTT_MEMORY_DEVICE_TYPE_VENDOR_SPECIFIC_TYPE
0xFF

///
--
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")





Re: [PATCH V8 3/3] OvmfPkg: Enable TDX in ResetVector

Yao, Jiewen
 

I propose to submit independent patch with independent metadata (2 tables) – don’t complicate thing.

 

We can revisit to see if there is need to merge to 1 table or how to merge, as a separate/standalone patch.

 

Thank you

Yao Jiewen

 

 

From: Singh, Brijesh <brijesh.singh@...>
Sent: Friday, October 1, 2021 1:40 AM
To: Xu, Min M <min.m.xu@...>; devel@edk2.groups.io; kraxel@...; Yao, Jiewen <jiewen.yao@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>; Justen, Jordan L <jordan.l.justen@...>; Erdem Aktas <erdemaktas@...>; James Bottomley <jejb@...>; Lendacky, Thomas <Thomas.Lendacky@...>
Subject: Re: [edk2-devel] [PATCH V8 3/3] OvmfPkg: Enable TDX in ResetVector

 

[AMD Official Use Only]

 

Yes, I will try to make it work for the unified Metadata. Let's do it indepent of SNP and TDX series. You can pick the generic patch from my series and add the additional fields we need for the TDX and submit it.

 


From: Xu, Min M <min.m.xu@...>
Sent: Thursday, September 30, 2021 12:31:56 AM
To: devel@edk2.groups.io <devel@edk2.groups.io>; Singh, Brijesh <brijesh.singh@...>; kraxel@... <kraxel@...>; Yao, Jiewen <jiewen.yao@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>; Justen, Jordan L <jordan.l.justen@...>; Erdem Aktas <erdemaktas@...>; James Bottomley <jejb@...>; Lendacky, Thomas <Thomas.Lendacky@...>
Subject: RE: [edk2-devel] [PATCH V8 3/3] OvmfPkg: Enable TDX in ResetVector

 

[AMD Official Use Only]

 

Hi, Brijesh

In the current discussion there are 2 options for the metadata, a unified Metadata and 2 separate Metadata (SEV and TDX metadata).

My understanding to your last mail is that you’re going to use the unified Metadata option, right?

 

As to the offset of metadata, absolute offset is a good idea. I will update it in my next version.

 

Thanks!

Min

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Brijesh Singh via groups.io
Sent: Tuesday, September 28, 2021 11:24 PM
To: Xu, Min M <min.m.xu@...>; devel@edk2.groups.io; kraxel@...
Cc: Yao, Jiewen <jiewen.yao@...>; Ard Biesheuvel <ardb+tianocore@...>; Justen, Jordan L <jordan.l.justen@...>; Erdem Aktas <erdemaktas@...>; James Bottomley <jejb@...>; Lendacky, Thomas <Thomas.Lendacky@...>
Subject: Re: [edk2-devel] [PATCH V8 3/3] OvmfPkg: Enable TDX in ResetVector

 

[AMD Official Use Only]

 

May I ask to use the OvmfMetadata instead of the of TdxMetadata for the Guided structure name label (same as what I did in SNP series patch #4). If you can send the metadata introduction as a patch separately then add the TDX descriptor in TDX series. I can try to make it work for the SNP series and add SNP specific descriptors. Additionally, I think you want to provide an absolute offset for the start of the metadata instead relative value so that VMM can very easily reach to the start of metadata. 

e.g

 

+OvmfMetadataOffsetStart:
+  DD      (fourGigabytes - OvmfMetadataGuid - 16)
+  DW      OvmfMetadataOffsetEnd - OvmfMetadataOffsetStart
+  DB      0x35, 0x65, 0x7a, 0xe4, 0x4a, 0x98, 0x98, 0x47
+  DB      0x86, 0x5e, 0x46, 0x85, 0xa7, 0xbf, 0x8e, 0xc2
+OvmfMetadataOffsetEnd:

 

For SNP series, I will 3 section types #1 CPUID, # Secrets, and #3 SEC_MEM and will probably add a total of 3 more descriptors. 

 


From: Xu, Min M <min.m.xu@...>
Sent: Tuesday, September 28, 2021 2:35 AM
To: devel@edk2.groups.io <devel@edk2.groups.io>; kraxel@... <kraxel@...>
Cc: Yao, Jiewen <jiewen.yao@...>; Ard Biesheuvel <ardb+tianocore@...>; Justen, Jordan L <jordan.l.justen@...>; Singh, Brijesh <brijesh.singh@...>; Erdem Aktas <erdemaktas@...>; James Bottomley <jejb@...>; Lendacky, Thomas <Thomas.Lendacky@...>
Subject: RE: [edk2-devel] [PATCH V8 3/3] OvmfPkg: Enable TDX in ResetVector

 

On September 28, 2021 12:43 PM, Gerd Hoffmann wrote:
>   Hi,
>
> > > Can you move the metadata changes to a separate patch please?
> > Yes, the metadata changes will be in a separate patch in the next version.
>
> Can you also add a comment block documenting the format?  Not only those
> parts which are used for TDVF, but everything?  The description in tdx-virtual-
> firmware-design-guide-rev-1.pdf seems to be incomplete, specifically the
> option to use the table for TD memory allocation (as mentioned by Jiewen) is
> not covered.  And possibly there is more which is missing ...
Sure. I will add the comment in IntelTdxMetadata.asm to describe the format of Tdx Metadata.
Here is the PR I would send as the next version. https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F2018&amp;data=04%7C01%7Cbrijesh.singh%40amd.com%7Cf49ea5bc7d79474e572108d982529cbd%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637684113590273535%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bGOxYMIKtHYKhcfk0Wt4qoIgiz3b9DM%2FAD%2Fui3ByVrU%3D&amp;reserved=0
You can have a preliminary review if you want.
>
> thanks,
>   Gerd
>
>
>
>
>


[PATCH v7 1/1] MdePkg/BaseLib: Add QuickSort function on BaseLib

IanX Kuo
 

From: IanX Kuo <ianx.kuo@intel.com>

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3675

Add QuickSort function into BaseLib

Cc: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: IanX Kuo <ianx.kuo@intel.com>
---
MdePkg/Include/Library/BaseLib.h | 49 ++++++++
MdePkg/Library/BaseLib/BaseLib.inf | 1 +
MdePkg/Library/BaseLib/QuickSort.c | 116 ++++++++++++++++++
.../Library/BaseLib/UnitTestHostBaseLib.inf | 3 +-
4 files changed, 168 insertions(+), 1 deletion(-)
create mode 100644 MdePkg/Library/BaseLib/QuickSort.c

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/Base=
Lib.h
index 2452c1d92e..0ae0f4e6af 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -2856,6 +2856,55 @@ RemoveEntryList (
//=0D
// Math Services=0D
//=0D
+/**=0D
+ Prototype for comparison function for any two element types.=0D
+=0D
+ @param[in] Buffer1 The pointer to first buffer.=0D
+ @param[in] Buffer2 The pointer to second buffer.=0D
+=0D
+ @retval 0 Buffer1 equal to Buffer2.=0D
+ @return <0 Buffer1 is less than Buffer2.=0D
+ @return >0 Buffer1 is greater than Buffer2.=0D
+**/=0D
+typedef=0D
+INTN=0D
+(EFIAPI *BASE_SORT_COMPARE)(=0D
+ IN CONST VOID *Buffer1,=0D
+ IN CONST VOID *Buffer2=0D
+ );=0D
+=0D
+/**=0D
+ This function is identical to perform QuickSort,=0D
+ except that is uses the pre-allocated buffer so the in place sorting doe=
s not need to=0D
+ allocate and free buffers constantly.=0D
+=0D
+ Each element must be equal sized.=0D
+=0D
+ if BufferToSort is NULL, then ASSERT.=0D
+ if CompareFunction is NULL, then ASSERT.=0D
+ if BufferOneElement is NULL, then ASSERT.=0D
+ if ElementSize is < 1, then ASSERT.=0D
+=0D
+ if Count is < 2 then perform no action.=0D
+=0D
+ @param[in, out] BufferToSort on call a Buffer of (possibly sorted) ele=
ments=0D
+ on return a buffer of sorted elements=0D
+ @param[in] Count the number of elements in the buffer to s=
ort=0D
+ @param[in] ElementSize Size of an element in bytes=0D
+ @param[in] CompareFunction The function to call to perform the compa=
rison=0D
+ of any 2 elements=0D
+ @param[out] BufferOneElement Caller provided buffer whose size equals =
to ElementSize.=0D
+ It's used by QuickSort() for swapping in =
sorting.=0D
+**/=0D
+VOID=0D
+EFIAPI=0D
+QuickSort (=0D
+ IN OUT VOID *BufferToSort,=0D
+ IN CONST UINTN Count,=0D
+ IN CONST UINTN ElementSize,=0D
+ IN BASE_SORT_COMPARE CompareFunction,=0D
+ OUT VOID *BufferOneElement=0D
+ );=0D
=0D
/**=0D
Shifts a 64-bit integer left between 0 and 63 bits. The low bits are fil=
led=0D
diff --git a/MdePkg/Library/BaseLib/BaseLib.inf b/MdePkg/Library/BaseLib/Ba=
seLib.inf
index 6efa5315b6..cebda3b210 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -32,6 +32,7 @@
SwapBytes16.c=0D
LongJump.c=0D
SetJump.c=0D
+ QuickSort.c=0D
RShiftU64.c=0D
RRotU64.c=0D
RRotU32.c=0D
diff --git a/MdePkg/Library/BaseLib/QuickSort.c b/MdePkg/Library/BaseLib/Qu=
ickSort.c
new file mode 100644
index 0000000000..a825c072b0
--- /dev/null
+++ b/MdePkg/Library/BaseLib/QuickSort.c
@@ -0,0 +1,116 @@
+/** @file=0D
+ Math worker functions.=0D
+=0D
+ Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>=0D
+ SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+=0D
+**/=0D
+=0D
+#include "BaseLibInternals.h"=0D
+=0D
+/**=0D
+ This function is identical to perform QuickSort,=0D
+ except that is uses the pre-allocated buffer so the in place sorting doe=
s not need to=0D
+ allocate and free buffers constantly.=0D
+=0D
+ Each element must be equal sized.=0D
+=0D
+ if BufferToSort is NULL, then ASSERT.=0D
+ if CompareFunction is NULL, then ASSERT.=0D
+ if BufferOneElement is NULL, then ASSERT.=0D
+ if ElementSize is < 1, then ASSERT.=0D
+=0D
+ if Count is < 2 then perform no action.=0D
+=0D
+ @param[in, out] BufferToSort on call a Buffer of (possibly sorted) ele=
ments=0D
+ on return a buffer of sorted elements=0D
+ @param[in] Count the number of elements in the buffer to s=
ort=0D
+ @param[in] ElementSize Size of an element in bytes=0D
+ @param[in] CompareFunction The function to call to perform the compa=
rison=0D
+ of any 2 elements=0D
+ @param[out] BufferOneElement Caller provided buffer whose size equals =
to ElementSize.=0D
+ It's used by QuickSort() for swapping in =
sorting.=0D
+**/=0D
+VOID=0D
+EFIAPI=0D
+QuickSort (=0D
+ IN OUT VOID *BufferToSort,=0D
+ IN CONST UINTN Count,=0D
+ IN CONST UINTN ElementSize,=0D
+ IN BASE_SORT_COMPARE CompareFunction,=0D
+ OUT VOID *BufferOneElement=0D
+ )=0D
+{=0D
+ VOID *Pivot;=0D
+ UINTN LoopCount;=0D
+ UINTN NextSwapLocation;=0D
+=0D
+ ASSERT (BufferToSort !=3D NULL);=0D
+ ASSERT (CompareFunction !=3D NULL);=0D
+ ASSERT (BufferOneElement !=3D NULL);=0D
+ ASSERT (ElementSize >=3D 1);=0D
+=0D
+ if (Count < 2) {=0D
+ return;=0D
+ }=0D
+=0D
+ NextSwapLocation =3D 0;=0D
+=0D
+ //=0D
+ // pick a pivot (we choose last element)=0D
+ //=0D
+ Pivot =3D ((UINT8*) BufferToSort + ((Count - 1) * ElementSize));=0D
+=0D
+ //=0D
+ // Now get the pivot such that all on "left" are below it=0D
+ // and everything "right" are above it=0D
+ //=0D
+ for (LoopCount =3D 0; LoopCount < Count -1; LoopCount++) {=0D
+ //=0D
+ // if the element is less than or equal to the pivot=0D
+ //=0D
+ if (CompareFunction ((VOID*) ((UINT8*) BufferToSort + ((LoopCount) * E=
lementSize)), Pivot) <=3D 0){=0D
+ //=0D
+ // swap=0D
+ //=0D
+ CopyMem (BufferOneElement, (UINT8*) BufferToSort + (NextSwapLocation=
* ElementSize), ElementSize);=0D
+ CopyMem ((UINT8*) BufferToSort + (NextSwapLocation * ElementSize), (=
UINT8*) BufferToSort + ((LoopCount) * ElementSize), ElementSize);=0D
+ CopyMem ((UINT8*) BufferToSort + ((LoopCount)*ElementSize), BufferOn=
eElement, ElementSize);=0D
+=0D
+ //=0D
+ // increment NextSwapLocation=0D
+ //=0D
+ NextSwapLocation++;=0D
+ }=0D
+ }=0D
+ //=0D
+ // swap pivot to it's final position (NextSwapLocation)=0D
+ //=0D
+ CopyMem (BufferOneElement, Pivot, ElementSize);=0D
+ CopyMem (Pivot, (UINT8*) BufferToSort + (NextSwapLocation * ElementSize)=
, ElementSize);=0D
+ CopyMem ((UINT8*) BufferToSort + (NextSwapLocation * ElementSize), Buffe=
rOneElement, ElementSize);=0D
+=0D
+ //=0D
+ // Now recurse on 2 partial lists. neither of these will have the 'pivo=
t' element=0D
+ // IE list is sorted left half, pivot element, sorted right half...=0D
+ //=0D
+ if (NextSwapLocation >=3D 2) {=0D
+ QuickSort (=0D
+ BufferToSort,=0D
+ NextSwapLocation,=0D
+ ElementSize,=0D
+ CompareFunction,=0D
+ BufferOneElement=0D
+ );=0D
+ }=0D
+=0D
+ if ((Count - NextSwapLocation - 1) >=3D 2) {=0D
+ QuickSort (=0D
+ (UINT8 *)BufferToSort + (NextSwapLocation + 1) * ElementSize,=0D
+ Count - NextSwapLocation - 1,=0D
+ ElementSize,=0D
+ CompareFunction,=0D
+ BufferOneElement=0D
+ );=0D
+ }=0D
+}=0D
diff --git a/MdePkg/Library/BaseLib/UnitTestHostBaseLib.inf b/MdePkg/Librar=
y/BaseLib/UnitTestHostBaseLib.inf
index eae1a7158d..d09bd12bef 100644
--- a/MdePkg/Library/BaseLib/UnitTestHostBaseLib.inf
+++ b/MdePkg/Library/BaseLib/UnitTestHostBaseLib.inf
@@ -1,7 +1,7 @@
## @file=0D
# Base Library implementation for use with host based unit tests.=0D
#=0D
-# Copyright (c) 2007 - 2020, Intel Corporation. All rights reserved.<BR>=
=0D
+# Copyright (c) 2007 - 2021, Intel Corporation. All rights reserved.<BR>=
=0D
# Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>=
=0D
# Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.<BR>=0D
# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All righ=
ts reserved.<BR>=0D
@@ -33,6 +33,7 @@
SwapBytes16.c=0D
LongJump.c=0D
SetJump.c=0D
+ QuickSort.c=0D
RShiftU64.c=0D
RRotU64.c=0D
RRotU32.c=0D
--=20
2.30.0.windows.1


[PATCH v7 0/1] Add function QuickSort into MdePkg/BaseLib

IanX Kuo
 

From: IanX Kuo <ianx.kuo@intel.com>

First change
1. MdePkg/BaseLib: Add QuickSort function

It need to seperate to second change
2. MdeModulePkg/SortLib: Use QuickSort instead of QuickSortWorker 3. CryptLib/CryptLib: Remove duplicate QuickSortWorker 4. CpuCacheInfoLib: Remove MdeModulePkg dependency

IanX Kuo (1):
MdePkg/BaseLib: Add QuickSort function on BaseLib

MdePkg/Include/Library/BaseLib.h | 49 ++++++++
MdePkg/Library/BaseLib/BaseLib.inf | 1 +
MdePkg/Library/BaseLib/QuickSort.c | 116 ++++++++++++++++++
.../Library/BaseLib/UnitTestHostBaseLib.inf | 3 +-
4 files changed, 168 insertions(+), 1 deletion(-)
create mode 100644 MdePkg/Library/BaseLib/QuickSort.c

--
2.30.0.windows.1


Re: Progress on getting Uncrustify working for EDK2?

Andrew Fish
 



On Oct 7, 2021, at 1:43 PM, Marvin Häuser <mhaeuser@...> wrote:

Hey Mike,
Hey Andrew,

I'll just reply to both mails at once :)

On 07/10/2021 19:36, Andrew Fish wrote:


On Oct 7, 2021, at 1:19 PM, Michael D Kinney <michael.d.kinney@...> wrote:

Hi Marvin,

Some comments below.

Mike

-----Original Message-----
From:devel@edk2.groups.io<devel@edk2.groups.io> On Behalf Of Marvin Häuser
Sent: Thursday, October 7, 2021 11:31 AM
To: Leif Lindholm <leif@...>;devel@edk2.groups.io;mikuback@...
Cc:rebecca@...; Michael Kubacki <Michael.Kubacki@...>; Bret Barkelew <Bret.Barkelew@...>;
Kinney, Michael D <michael.d.kinney@...>
Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?

Good day,

+1, but while you're at it, can we have arguments not align to the
function name...

  Status = Test (
             a
             );

... but to the next natural indentation level?

  Status = Test (
    a
    );

Basically no IDE I have seen supports EDK II's style, and I wouldn't be
keen on writing known-broken style to then rely on Uncrustify to fix it.

I also have heard some controversy regarding casts off-list, where some
prefer no spaces after casts to stress the evaluation order, and some
prefer spaces to have clearer visuals (as a cast *ideally* would be
something rare that requires good justification). Just throwing that out
there.


For things unrelated to autoformat (so semi-offtopic) but still relevant
to the coding spec:

1. Allow STATIC functions (if the debugging concerns are still relevant,
there could be another level of indirection, like RELEASE_STATIC)?

Debugging concerns are no longer relevant.  The suggestion in the BZ below
is to remove the STATIC macro and allow EDK II sources to add 'static'
to any functions it makes sense to use on.

https://bugzilla.tianocore.org/show_bug.cgi?id=1766

Thanks! I'd keep STATIC actually just for the sake of not doing no-op changes that do not really do anything and for consistency with CONST, but whatever works really.



2. Allow variable assignments on definition (basically non-static CONST
variables are banned...)?

Are referring to use of pre-initialized CONST variables declared within
a function?  I think Bret brought this topic up when implementing some
unit tests and the suggestion to pass ECCC was to promote them to
pre-initialized CONST global variables.

Yes.


The challenges we have seen in the past with pre-initialized variables within
a function is that they can cause compilers to inject use of memcpy() calls,
especially if the variable being initialized on the stack is a structure.
These cause build breaks today.

This issue is independent of CONST. I’m not sure a coding style tool is smart enough to catch this generically? You need an understanding of C types to know if the local variable assignment is going to trigger a memcpy().

What I’ve seen in the real world is the firmware compiles with -Os or LTO to fit int he ROM for DEBUG and RELEASE, and the optimizer optimizes away the call to memcpy. Then if you try to build NOOPT (or over ride the compiler flags on an individual driver/lib) you fail to link as only the NOOPT build injects the memcpy.

+1


Thus I think the best way to enforce this rule is to compile a project NOOPT. I’m trying to remember are there flags to built to tell it to compile and skip the FD construction? Maybe we should advocate platforms add a NOOPT build target that just compiles the code, but does not create the FD?

I know there were stability concerns with intrinsics in the past, but memcpy() is in the standard, and the rest remained stable to my knowledge. Maybe it's time to fix the issues at the root? Works for us:
https://github.com/acidanthera/OpenCorePkg/tree/master/Library/OcCompilerIntrinsicsLib


Marvin,

Good point. This would make the rule moot. So maybe just removing the requirement would be the easiest long term fix. 

Other embedded projects I know of do this too, and as you point out the compilers keep these APIs standard for folks the provide their own runtimes.

Thanks,

Andrew Fish

Best regards,
Marvin


Thanks,

Andrew Fish



3. Allow variable declarations at any scope (I had some nasty shadowing
bugs before, probably prohibit shadowing with warnings)?

By shadowing do you mean the declaration of the same variable name in
multiple scoped within the same function?


4. Require that exactly all function declarations and all function
definitions with no prior declaration must be documented (first
direction is enforcing docs, second is prohibiting doc duplication, I've
seen them go out-of-sync plenty of times)?

I agree that this can reduce duplication and sync issues.  The uncrustify
tool being discussed here could not help clean this up or enforce this
type of rule.  It is a good topic, but may need to be split out into its
own thread.


The latter bunch would not require any autoformat rules or reformatation
of existing code, but would be target only new submissions in my
opinion. Thoughts?


Thanks for your efforts!

Best regards,
Marvin


Am 07.10.2021 um 12:48 schrieb Leif Lindholm:
Hi Michael,

Apologies, I've owed you a response (promised off-list) for a while
now.

First, let me say I hugely appreciate this effort. Apart from aligning
the codebase(s), this will reduce manual reviewing effort
substantially, as well as cutting down on number of rework cycles for
developers.

Looking at the changes to (well, the comments in) uncrustify, this
seems to be constrained to:
- Newline after '(' for multi-line function calls.
- Dealing with "(("/"))" for DEBUG macros.
- Function pointer typedefs:
  - typedef\nEFIAPI
  - closing parentheses indentation

I don't think I've made any secret over the years that I am not a
massive fan of the EDK2 coding style in general. So I think for any
of its quirks that are substantial enough that they require not just
custom configuration but actual new function added to existing code
conformance tools, this would be an excellent point to sanitise the
coding style instead.

Taking these in order:

Newline after '('
-----------------
I think we already reached a level of flexibility around this, where
we don't actually enforce this (or single argument per
line). Personally, I'd be happy to update the coding style as
required instead.

DEBUG macro parentheses
-----------------------
How does uncrustify treat DEBUG macros without this modification?
Do we start getting everything turned into multi-level indented
multi-line statements without this change?

Function pointer typedefs:
--------------------------
I don't see that function pointer typedefs need to rigidly follow the
same pattern as the declaration of functions implementing them. Could
we update the coding style (if needed) instead?

Best Regards,

Leif

On Mon, Aug 16, 2021 at 16:00:38 -0400, Michael Kubacki wrote:
The edk2 branch was created here:
https://github.com/makubacki/edk2/tree/uncrustify_poc_2

We have a Project Mu fork with custom changes to the Uncrustify tool to help
comply with EDK II formatting here:
https://dev.azure.com/projectmu/_git/Uncrustify

The latest information about the status and how to experiment with the
configuration file and the tool are in that fork:
https://dev.azure.com/projectmu/Uncrustify/_wiki/wikis/Uncrustify.wiki/1/Project-Mu-(EDK-II)-Fork-Readme

That said, I have also finished a CI plugin to run Uncrustify that should be
ready soon to initially deploy in Project Mu. Before doing so, I am trying
to settle on an initial configuration file that less strictly but more
reliably formats the code than in the examples in those branches. For
example, remove heuristics that when run against the same set of code
multiple times can produce different results. An example would be a rule
that reformats code because it exceeds a specified column width on one run
but on the next run that reformatted code triggers a different rule to
further align the code and so on. At least initially, some rules might be
tweaked in a more conservative approach that can be tightened in the future.
Once this configuration file is ready, we will baseline Project Mu code as
an example and turn on the plugin. The CI plugin runs Uncrustify against
modified files and if there's any changes, indicating a formatting
deviation, the diff chunks are saved in a log so they can be viewed as a
build artifact.

I am making progress on the updated config file and I should be able to post
a "uncrustify_poc_3" branch soon with the results.

Regarding indentation, Marvin is right that Uncrustify cannot support edk2
indentation style out-of-box. Some changes are made in that fork to handle
the formatting. At this point, it can handle the indentation in the cases
I've seen. Uncrustify does potentially give us the ability to massively
deploy changes across the codebase in case a decision were made to change
the style.

Thanks,
Michael

On 8/16/2021 3:39 PM, Marvin Häuser wrote:
Hey Rebecca,

I think even Uncrustify has issues with the EDK II indentation style.
You might want to check the UEFI Talkbox Discord server, I had a brief
chat with Michael about it there. I don't think realistically any tool
supports EDK II's indentation style however, so I'd propose it is
changed. This could be for new submissions only, or actually the entire
codebase could be reformatted at once with a good tool setup. While this
screws with git blame, the (to my understanding) decided on CRLF -> LF
change does that anyway, so at least two evils could be dealt with in
one go really.

Best regards,
Marvin

On 16/08/2021 21:34, Rebecca Cran wrote:

cc devel@ .

On 8/16/21 1:33 PM, Rebecca Cran wrote:

I noticed a message on Twitter about an idea of using Uncrustify
for EDK2 instead of the ECC tool, and came across https://www.mail-
archive.com/search?l@...&q=subject:%22Re%5C%3A+%5C%5Bedk2%5C-
devel%5C%5D+TianoCore+Community+Meeting+Minutes+%5C-+2%5C%2F4%22&o=newest&f=1
.

I was wondering if there's been any progress on it that I could
check out?


Michael Kubacki: in that message, you said:

"I'm planning to put up a branch that we can use as a reference
for a conversation around uncrustify in the next couple of
weeks."


Did you end up creating that branch, and if so could you provide
a link to it please?


--
Rebecca Cran






















Re: Progress on getting Uncrustify working for EDK2?

Marvin Häuser
 

Hey Mike,
Hey Andrew,

I'll just reply to both mails at once :)

On 07/10/2021 19:36, Andrew Fish wrote:


On Oct 7, 2021, at 1:19 PM, Michael D Kinney <michael.d.kinney@intel.com> wrote:

Hi Marvin,

Some comments below.

Mike

-----Original Message-----
From:devel@edk2.groups.io<devel@edk2.groups.io> On Behalf Of Marvin Häuser
Sent: Thursday, October 7, 2021 11:31 AM
To: Leif Lindholm <leif@nuviainc.com>;devel@edk2.groups.io;mikuback@linux.microsoft.com
Cc:rebecca@nuviainc.com; Michael Kubacki <Michael.Kubacki@microsoft.com>; Bret Barkelew <Bret.Barkelew@microsoft.com>;
Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?

Good day,

+1, but while you're at it, can we have arguments not align to the
function name...

  Status = Test (
             a
             );

... but to the next natural indentation level?

  Status = Test (
    a
    );

Basically no IDE I have seen supports EDK II's style, and I wouldn't be
keen on writing known-broken style to then rely on Uncrustify to fix it.

I also have heard some controversy regarding casts off-list, where some
prefer no spaces after casts to stress the evaluation order, and some
prefer spaces to have clearer visuals (as a cast *ideally* would be
something rare that requires good justification). Just throwing that out
there.


For things unrelated to autoformat (so semi-offtopic) but still relevant
to the coding spec:

1. Allow STATIC functions (if the debugging concerns are still relevant,
there could be another level of indirection, like RELEASE_STATIC)?
Debugging concerns are no longer relevant.  The suggestion in the BZ below
is to remove the STATIC macro and allow EDK II sources to add 'static'
to any functions it makes sense to use on.

https://bugzilla.tianocore.org/show_bug.cgi?id=1766
Thanks! I'd keep STATIC actually just for the sake of not doing no-op changes that do not really do anything and for consistency with CONST, but whatever works really.



2. Allow variable assignments on definition (basically non-static CONST
variables are banned...)?
Are referring to use of pre-initialized CONST variables declared within
a function?  I think Bret brought this topic up when implementing some
unit tests and the suggestion to pass ECCC was to promote them to
pre-initialized CONST global variables.
Yes.


The challenges we have seen in the past with pre-initialized variables within
a function is that they can cause compilers to inject use of memcpy() calls,
especially if the variable being initialized on the stack is a structure.
These cause build breaks today.
This issue is independent of CONST. I’m not sure a coding style tool is smart enough to catch this generically? You need an understanding of C types to know if the local variable assignment is going to trigger a memcpy().

What I’ve seen in the real world is the firmware compiles with -Os or LTO to fit int he ROM for DEBUG and RELEASE, and the optimizer optimizes away the call to memcpy. Then if you try to build NOOPT (or over ride the compiler flags on an individual driver/lib) you fail to link as only the NOOPT build injects the memcpy.
+1


Thus I think the best way to enforce this rule is to compile a project NOOPT. I’m trying to remember are there flags to built to tell it to compile and skip the FD construction? Maybe we should advocate platforms add a NOOPT build target that just compiles the code, but does not create the FD?
I know there were stability concerns with intrinsics in the past, but memcpy() is in the standard, and the rest remained stable to my knowledge. Maybe it's time to fix the issues at the root? Works for us:
https://github.com/acidanthera/OpenCorePkg/tree/master/Library/OcCompilerIntrinsicsLib

Best regards,
Marvin


Thanks,

Andrew Fish



3. Allow variable declarations at any scope (I had some nasty shadowing
bugs before, probably prohibit shadowing with warnings)?
By shadowing do you mean the declaration of the same variable name in
multiple scoped within the same function?


4. Require that exactly all function declarations and all function
definitions with no prior declaration must be documented (first
direction is enforcing docs, second is prohibiting doc duplication, I've
seen them go out-of-sync plenty of times)?
I agree that this can reduce duplication and sync issues.  The uncrustify
tool being discussed here could not help clean this up or enforce this
type of rule.  It is a good topic, but may need to be split out into its
own thread.


The latter bunch would not require any autoformat rules or reformatation
of existing code, but would be target only new submissions in my
opinion. Thoughts?


Thanks for your efforts!

Best regards,
Marvin


Am 07.10.2021 um 12:48 schrieb Leif Lindholm:
Hi Michael,

Apologies, I've owed you a response (promised off-list) for a while
now.

First, let me say I hugely appreciate this effort. Apart from aligning
the codebase(s), this will reduce manual reviewing effort
substantially, as well as cutting down on number of rework cycles for
developers.

Looking at the changes to (well, the comments in) uncrustify, this
seems to be constrained to:
- Newline after '(' for multi-line function calls.
- Dealing with "(("/"))" for DEBUG macros.
- Function pointer typedefs:
  - typedef\nEFIAPI
  - closing parentheses indentation

I don't think I've made any secret over the years that I am not a
massive fan of the EDK2 coding style in general. So I think for any
of its quirks that are substantial enough that they require not just
custom configuration but actual new function added to existing code
conformance tools, this would be an excellent point to sanitise the
coding style instead.

Taking these in order:

Newline after '('
-----------------
I think we already reached a level of flexibility around this, where
we don't actually enforce this (or single argument per
line). Personally, I'd be happy to update the coding style as
required instead.

DEBUG macro parentheses
-----------------------
How does uncrustify treat DEBUG macros without this modification?
Do we start getting everything turned into multi-level indented
multi-line statements without this change?

Function pointer typedefs:
--------------------------
I don't see that function pointer typedefs need to rigidly follow the
same pattern as the declaration of functions implementing them. Could
we update the coding style (if needed) instead?

Best Regards,

Leif

On Mon, Aug 16, 2021 at 16:00:38 -0400, Michael Kubacki wrote:
The edk2 branch was created here:
https://github.com/makubacki/edk2/tree/uncrustify_poc_2

We have a Project Mu fork with custom changes to the Uncrustify tool to help
comply with EDK II formatting here:
https://dev.azure.com/projectmu/_git/Uncrustify

The latest information about the status and how to experiment with the
configuration file and the tool are in that fork:
https://dev.azure.com/projectmu/Uncrustify/_wiki/wikis/Uncrustify.wiki/1/Project-Mu-(EDK-II)-Fork-Readme

That said, I have also finished a CI plugin to run Uncrustify that should be
ready soon to initially deploy in Project Mu. Before doing so, I am trying
to settle on an initial configuration file that less strictly but more
reliably formats the code than in the examples in those branches. For
example, remove heuristics that when run against the same set of code
multiple times can produce different results. An example would be a rule
that reformats code because it exceeds a specified column width on one run
but on the next run that reformatted code triggers a different rule to
further align the code and so on. At least initially, some rules might be
tweaked in a more conservative approach that can be tightened in the future.
Once this configuration file is ready, we will baseline Project Mu code as
an example and turn on the plugin. The CI plugin runs Uncrustify against
modified files and if there's any changes, indicating a formatting
deviation, the diff chunks are saved in a log so they can be viewed as a
build artifact.

I am making progress on the updated config file and I should be able to post
a "uncrustify_poc_3" branch soon with the results.

Regarding indentation, Marvin is right that Uncrustify cannot support edk2
indentation style out-of-box. Some changes are made in that fork to handle
the formatting. At this point, it can handle the indentation in the cases
I've seen. Uncrustify does potentially give us the ability to massively
deploy changes across the codebase in case a decision were made to change
the style.

Thanks,
Michael

On 8/16/2021 3:39 PM, Marvin Häuser wrote:
Hey Rebecca,

I think even Uncrustify has issues with the EDK II indentation style.
You might want to check the UEFI Talkbox Discord server, I had a brief
chat with Michael about it there. I don't think realistically any tool
supports EDK II's indentation style however, so I'd propose it is
changed. This could be for new submissions only, or actually the entire
codebase could be reformatted at once with a good tool setup. While this
screws with git blame, the (to my understanding) decided on CRLF -> LF
change does that anyway, so at least two evils could be dealt with in
one go really.

Best regards,
Marvin

On 16/08/2021 21:34, Rebecca Cran wrote:

cc devel@ .

On 8/16/21 1:33 PM, Rebecca Cran wrote:

I noticed a message on Twitter about an idea of using Uncrustify
for EDK2 instead of the ECC tool, and came across https://www.mail-
archive.com/search?l=devel@edk2.groups.io&q=subject:%22Re%5C%3A+%5C%5Bedk2%5C-
devel%5C%5D+TianoCore+Community+Meeting+Minutes+%5C-+2%5C%2F4%22&o=newest&f=1
.

I was wondering if there's been any progress on it that I could
check out?


Michael Kubacki: in that message, you said:

"I'm planning to put up a branch that we can use as a reference
for a conversation around uncrustify in the next couple of
weeks."


Did you end up creating that branch, and if so could you provide
a link to it please?


--
Rebecca Cran












Re: Progress on getting Uncrustify working for EDK2?

Andrew Fish
 



On Oct 7, 2021, at 1:19 PM, Michael D Kinney <michael.d.kinney@...> wrote:

Hi Marvin,

Some comments below.

Mike

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Marvin Häuser
Sent: Thursday, October 7, 2021 11:31 AM
To: Leif Lindholm <leif@...>; devel@edk2.groups.io; mikuback@...
Cc: rebecca@...; Michael Kubacki <Michael.Kubacki@...>; Bret Barkelew <Bret.Barkelew@...>;
Kinney, Michael D <michael.d.kinney@...>
Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?

Good day,

+1, but while you're at it, can we have arguments not align to the
function name...

  Status = Test (
             a
             );

... but to the next natural indentation level?

  Status = Test (
    a
    );

Basically no IDE I have seen supports EDK II's style, and I wouldn't be
keen on writing known-broken style to then rely on Uncrustify to fix it.

I also have heard some controversy regarding casts off-list, where some
prefer no spaces after casts to stress the evaluation order, and some
prefer spaces to have clearer visuals (as a cast *ideally* would be
something rare that requires good justification). Just throwing that out
there.


For things unrelated to autoformat (so semi-offtopic) but still relevant
to the coding spec:

1. Allow STATIC functions (if the debugging concerns are still relevant,
there could be another level of indirection, like RELEASE_STATIC)?

Debugging concerns are no longer relevant.  The suggestion in the BZ below 
is to remove the STATIC macro and allow EDK II sources to add 'static'
to any functions it makes sense to use on.

   https://bugzilla.tianocore.org/show_bug.cgi?id=1766


2. Allow variable assignments on definition (basically non-static CONST
variables are banned...)?

Are referring to use of pre-initialized CONST variables declared within
a function?  I think Bret brought this topic up when implementing some
unit tests and the suggestion to pass ECCC was to promote them to 
pre-initialized CONST global variables.

The challenges we have seen in the past with pre-initialized variables within
a function is that they can cause compilers to inject use of memcpy() calls,
especially if the variable being initialized on the stack is a structure.
These cause build breaks today.

This issue is independent of CONST. I’m not sure a coding style tool is smart enough to catch this generically? You need an understanding of C types to know if the local variable assignment is going to trigger a memcpy(). 

What I’ve seen in the real world is the firmware compiles with -Os or LTO to fit int he ROM for DEBUG and RELEASE, and the optimizer optimizes away the call to memcpy. Then if you try to build NOOPT (or over ride the compiler flags on an individual driver/lib) you fail to link as only the NOOPT build injects the memcpy. 

Thus I think the best way to enforce this rule is to compile a project NOOPT. I’m trying to remember are there flags to built to tell it to compile and skip the FD construction? Maybe we should advocate platforms add a NOOPT build target that just compiles the code, but does not create the FD?

Thanks,

Andrew Fish



3. Allow variable declarations at any scope (I had some nasty shadowing
bugs before, probably prohibit shadowing with warnings)?

By shadowing do you mean the declaration of the same variable name in
multiple scoped within the same function?


4. Require that exactly all function declarations and all function
definitions with no prior declaration must be documented (first
direction is enforcing docs, second is prohibiting doc duplication, I've
seen them go out-of-sync plenty of times)?

I agree that this can reduce duplication and sync issues.  The uncrustify
tool being discussed here could not help clean this up or enforce this
type of rule.  It is a good topic, but may need to be split out into its
own thread.


The latter bunch would not require any autoformat rules or reformatation
of existing code, but would be target only new submissions in my
opinion. Thoughts?


Thanks for your efforts!

Best regards,
Marvin


Am 07.10.2021 um 12:48 schrieb Leif Lindholm:
Hi Michael,

Apologies, I've owed you a response (promised off-list) for a while
now.

First, let me say I hugely appreciate this effort. Apart from aligning
the codebase(s), this will reduce manual reviewing effort
substantially, as well as cutting down on number of rework cycles for
developers.

Looking at the changes to (well, the comments in) uncrustify, this
seems to be constrained to:
- Newline after '(' for multi-line function calls.
- Dealing with "(("/"))" for DEBUG macros.
- Function pointer typedefs:
  - typedef\nEFIAPI
  - closing parentheses indentation

I don't think I've made any secret over the years that I am not a
massive fan of the EDK2 coding style in general. So I think for any
of its quirks that are substantial enough that they require not just
custom configuration but actual new function added to existing code
conformance tools, this would be an excellent point to sanitise the
coding style instead.

Taking these in order:

Newline after '('
-----------------
I think we already reached a level of flexibility around this, where
we don't actually enforce this (or single argument per
line). Personally, I'd be happy to update the coding style as
required instead.

DEBUG macro parentheses
-----------------------
How does uncrustify treat DEBUG macros without this modification?
Do we start getting everything turned into multi-level indented
multi-line statements without this change?

Function pointer typedefs:
--------------------------
I don't see that function pointer typedefs need to rigidly follow the
same pattern as the declaration of functions implementing them. Could
we update the coding style (if needed) instead?

Best Regards,

Leif

On Mon, Aug 16, 2021 at 16:00:38 -0400, Michael Kubacki wrote:
The edk2 branch was created here:
https://github.com/makubacki/edk2/tree/uncrustify_poc_2

We have a Project Mu fork with custom changes to the Uncrustify tool to help
comply with EDK II formatting here:
https://dev.azure.com/projectmu/_git/Uncrustify

The latest information about the status and how to experiment with the
configuration file and the tool are in that fork:
https://dev.azure.com/projectmu/Uncrustify/_wiki/wikis/Uncrustify.wiki/1/Project-Mu-(EDK-II)-Fork-Readme

That said, I have also finished a CI plugin to run Uncrustify that should be
ready soon to initially deploy in Project Mu. Before doing so, I am trying
to settle on an initial configuration file that less strictly but more
reliably formats the code than in the examples in those branches. For
example, remove heuristics that when run against the same set of code
multiple times can produce different results. An example would be a rule
that reformats code because it exceeds a specified column width on one run
but on the next run that reformatted code triggers a different rule to
further align the code and so on. At least initially, some rules might be
tweaked in a more conservative approach that can be tightened in the future.
Once this configuration file is ready, we will baseline Project Mu code as
an example and turn on the plugin. The CI plugin runs Uncrustify against
modified files and if there's any changes, indicating a formatting
deviation, the diff chunks are saved in a log so they can be viewed as a
build artifact.

I am making progress on the updated config file and I should be able to post
a "uncrustify_poc_3" branch soon with the results.

Regarding indentation, Marvin is right that Uncrustify cannot support edk2
indentation style out-of-box. Some changes are made in that fork to handle
the formatting. At this point, it can handle the indentation in the cases
I've seen. Uncrustify does potentially give us the ability to massively
deploy changes across the codebase in case a decision were made to change
the style.

Thanks,
Michael

On 8/16/2021 3:39 PM, Marvin Häuser wrote:
Hey Rebecca,

I think even Uncrustify has issues with the EDK II indentation style.
You might want to check the UEFI Talkbox Discord server, I had a brief
chat with Michael about it there. I don't think realistically any tool
supports EDK II's indentation style however, so I'd propose it is
changed. This could be for new submissions only, or actually the entire
codebase could be reformatted at once with a good tool setup. While this
screws with git blame, the (to my understanding) decided on CRLF -> LF
change does that anyway, so at least two evils could be dealt with in
one go really.

Best regards,
Marvin

On 16/08/2021 21:34, Rebecca Cran wrote:

cc devel@ .

On 8/16/21 1:33 PM, Rebecca Cran wrote:

I noticed a message on Twitter about an idea of using Uncrustify
for EDK2 instead of the ECC tool, and came across https://www.mail-
archive.com/search?l@...&q=subject:%22Re%5C%3A+%5C%5Bedk2%5C-
devel%5C%5D+TianoCore+Community+Meeting+Minutes+%5C-+2%5C%2F4%22&o=newest&f=1
.

I was wondering if there's been any progress on it that I could
check out?


Michael Kubacki: in that message, you said:

"I'm planning to put up a branch that we can use as a reference
for a conversation around uncrustify in the next couple of
weeks."


Did you end up creating that branch, and if so could you provide
a link to it please?


--
Rebecca Cran






















Re: Progress on getting Uncrustify working for EDK2?

Michael D Kinney
 

Hi Marvin,

Some comments below.

Mike

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Marvin Häuser
Sent: Thursday, October 7, 2021 11:31 AM
To: Leif Lindholm <leif@nuviainc.com>; devel@edk2.groups.io; mikuback@linux.microsoft.com
Cc: rebecca@nuviainc.com; Michael Kubacki <Michael.Kubacki@microsoft.com>; Bret Barkelew <Bret.Barkelew@microsoft.com>;
Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?

Good day,

+1, but while you're at it, can we have arguments not align to the
function name...

Status = Test (
a
);

... but to the next natural indentation level?

Status = Test (
a
);

Basically no IDE I have seen supports EDK II's style, and I wouldn't be
keen on writing known-broken style to then rely on Uncrustify to fix it.

I also have heard some controversy regarding casts off-list, where some
prefer no spaces after casts to stress the evaluation order, and some
prefer spaces to have clearer visuals (as a cast *ideally* would be
something rare that requires good justification). Just throwing that out
there.


For things unrelated to autoformat (so semi-offtopic) but still relevant
to the coding spec:

1. Allow STATIC functions (if the debugging concerns are still relevant,
there could be another level of indirection, like RELEASE_STATIC)?
Debugging concerns are no longer relevant. The suggestion in the BZ below
is to remove the STATIC macro and allow EDK II sources to add 'static'
to any functions it makes sense to use on.

https://bugzilla.tianocore.org/show_bug.cgi?id=1766


2. Allow variable assignments on definition (basically non-static CONST
variables are banned...)?
Are referring to use of pre-initialized CONST variables declared within
a function? I think Bret brought this topic up when implementing some
unit tests and the suggestion to pass ECCC was to promote them to
pre-initialized CONST global variables.

The challenges we have seen in the past with pre-initialized variables within
a function is that they can cause compilers to inject use of memcpy() calls,
especially if the variable being initialized on the stack is a structure.
These cause build breaks today.


3. Allow variable declarations at any scope (I had some nasty shadowing
bugs before, probably prohibit shadowing with warnings)?
By shadowing do you mean the declaration of the same variable name in
multiple scoped within the same function?


4. Require that exactly all function declarations and all function
definitions with no prior declaration must be documented (first
direction is enforcing docs, second is prohibiting doc duplication, I've
seen them go out-of-sync plenty of times)?
I agree that this can reduce duplication and sync issues. The uncrustify
tool being discussed here could not help clean this up or enforce this
type of rule. It is a good topic, but may need to be split out into its
own thread.


The latter bunch would not require any autoformat rules or reformatation
of existing code, but would be target only new submissions in my
opinion. Thoughts?


Thanks for your efforts!

Best regards,
Marvin


Am 07.10.2021 um 12:48 schrieb Leif Lindholm:
Hi Michael,

Apologies, I've owed you a response (promised off-list) for a while
now.

First, let me say I hugely appreciate this effort. Apart from aligning
the codebase(s), this will reduce manual reviewing effort
substantially, as well as cutting down on number of rework cycles for
developers.

Looking at the changes to (well, the comments in) uncrustify, this
seems to be constrained to:
- Newline after '(' for multi-line function calls.
- Dealing with "(("/"))" for DEBUG macros.
- Function pointer typedefs:
- typedef\nEFIAPI
- closing parentheses indentation

I don't think I've made any secret over the years that I am not a
massive fan of the EDK2 coding style in general. So I think for any
of its quirks that are substantial enough that they require not just
custom configuration but actual new function added to existing code
conformance tools, this would be an excellent point to sanitise the
coding style instead.

Taking these in order:

Newline after '('
-----------------
I think we already reached a level of flexibility around this, where
we don't actually enforce this (or single argument per
line). Personally, I'd be happy to update the coding style as
required instead.

DEBUG macro parentheses
-----------------------
How does uncrustify treat DEBUG macros without this modification?
Do we start getting everything turned into multi-level indented
multi-line statements without this change?

Function pointer typedefs:
--------------------------
I don't see that function pointer typedefs need to rigidly follow the
same pattern as the declaration of functions implementing them. Could
we update the coding style (if needed) instead?

Best Regards,

Leif

On Mon, Aug 16, 2021 at 16:00:38 -0400, Michael Kubacki wrote:
The edk2 branch was created here:
https://github.com/makubacki/edk2/tree/uncrustify_poc_2

We have a Project Mu fork with custom changes to the Uncrustify tool to help
comply with EDK II formatting here:
https://dev.azure.com/projectmu/_git/Uncrustify

The latest information about the status and how to experiment with the
configuration file and the tool are in that fork:
https://dev.azure.com/projectmu/Uncrustify/_wiki/wikis/Uncrustify.wiki/1/Project-Mu-(EDK-II)-Fork-Readme

That said, I have also finished a CI plugin to run Uncrustify that should be
ready soon to initially deploy in Project Mu. Before doing so, I am trying
to settle on an initial configuration file that less strictly but more
reliably formats the code than in the examples in those branches. For
example, remove heuristics that when run against the same set of code
multiple times can produce different results. An example would be a rule
that reformats code because it exceeds a specified column width on one run
but on the next run that reformatted code triggers a different rule to
further align the code and so on. At least initially, some rules might be
tweaked in a more conservative approach that can be tightened in the future.
Once this configuration file is ready, we will baseline Project Mu code as
an example and turn on the plugin. The CI plugin runs Uncrustify against
modified files and if there's any changes, indicating a formatting
deviation, the diff chunks are saved in a log so they can be viewed as a
build artifact.

I am making progress on the updated config file and I should be able to post
a "uncrustify_poc_3" branch soon with the results.

Regarding indentation, Marvin is right that Uncrustify cannot support edk2
indentation style out-of-box. Some changes are made in that fork to handle
the formatting. At this point, it can handle the indentation in the cases
I've seen. Uncrustify does potentially give us the ability to massively
deploy changes across the codebase in case a decision were made to change
the style.

Thanks,
Michael

On 8/16/2021 3:39 PM, Marvin Häuser wrote:
Hey Rebecca,

I think even Uncrustify has issues with the EDK II indentation style.
You might want to check the UEFI Talkbox Discord server, I had a brief
chat with Michael about it there. I don't think realistically any tool
supports EDK II's indentation style however, so I'd propose it is
changed. This could be for new submissions only, or actually the entire
codebase could be reformatted at once with a good tool setup. While this
screws with git blame, the (to my understanding) decided on CRLF -> LF
change does that anyway, so at least two evils could be dealt with in
one go really.

Best regards,
Marvin

On 16/08/2021 21:34, Rebecca Cran wrote:

cc devel@ .

On 8/16/21 1:33 PM, Rebecca Cran wrote:

I noticed a message on Twitter about an idea of using Uncrustify
for EDK2 instead of the ECC tool, and came across https://www.mail-
archive.com/search?l=devel@edk2.groups.io&q=subject:%22Re%5C%3A+%5C%5Bedk2%5C-
devel%5C%5D+TianoCore+Community+Meeting+Minutes+%5C-+2%5C%2F4%22&o=newest&f=1
.

I was wondering if there's been any progress on it that I could
check out?


Michael Kubacki: in that message, you said:

"I'm planning to put up a branch that we can use as a reference
for a conversation around uncrustify in the next couple of
weeks."


Did you end up creating that branch, and if so could you provide
a link to it please?


--
Rebecca Cran










Re: Progress on getting Uncrustify working for EDK2?

Michael D Kinney
 

Hi Leif,

Thanks for the feedback. Adjusting the EDK II C Coding Style should absolutely
be part of this discussion. We need to work towards specific proposals. Here are
the current open bugs against the EDK II C Coding Style. Please update or add new
for the changes you are suggesting.

https://bugzilla.tianocore.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&columnlist=product%2Ccomponent%2Cshort_desc%2Creporter&component=Documentation&f1=cf_documents&list_id=23944&o1=equals&product=EDK2&query_format=advanced&resolution=---&v1=EDK%20II%20C%20Coding%20Standards

2664 Discrepancies/inconsistencies in coding standards, style and examples
1698 Spurious rule about comment style in CCS 6.2.3
713 Update EDK II C Coding standard to state a stronger preference for 80 column line widths
714 Update EDK II C Coding Standards to allow multiple arguments per line in a function call
1766 Remove use of STATIC macros from EDK II C Coding Standard Specification
2391 Dangling word at end of Section 5.1.9 In-line assembler shall not be used
723 5.1.8 Typo provided should be proven
884 The cover.jpg file for the EDK II specs has the old style logo
839 Minor typographical errors

Additional comments below.

Thanks,

Mike

-----Original Message-----
From: Leif Lindholm <leif@nuviainc.com>
Sent: Thursday, October 7, 2021 3:48 AM
To: devel@edk2.groups.io; mikuback@linux.microsoft.com
Cc: mhaeuser@posteo.de; rebecca@nuviainc.com; Michael Kubacki <Michael.Kubacki@microsoft.com>; Bret Barkelew
<Bret.Barkelew@microsoft.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?

Hi Michael,

Apologies, I've owed you a response (promised off-list) for a while
now.

First, let me say I hugely appreciate this effort. Apart from aligning
the codebase(s), this will reduce manual reviewing effort
substantially, as well as cutting down on number of rework cycles for
developers.

Looking at the changes to (well, the comments in) uncrustify, this
seems to be constrained to:
- Newline after '(' for multi-line function calls.
- Dealing with "(("/"))" for DEBUG macros.
- Function pointer typedefs:
- typedef\nEFIAPI
- closing parentheses indentation

I don't think I've made any secret over the years that I am not a
massive fan of the EDK2 coding style in general. So I think for any
of its quirks that are substantial enough that they require not just
custom configuration but actual new function added to existing code
conformance tools, this would be an excellent point to sanitise the
coding style instead.

Taking these in order:

Newline after '('
-----------------
I think we already reached a level of flexibility around this, where
we don't actually enforce this (or single argument per
line). Personally, I'd be happy to update the coding style as
required instead.

Here is an example of a change that uncrustify did that I think you
are suggesting is not required with support for multiple params
per line. Correct?

Before Uncristify
=================
AsmCpuidEx (
CPUID_EXTENDED_STATE, CPUID_EXTENDED_STATE_SUB_LEAF,
&Eax.Uint32, &Ebx, &Ecx.Uint32, &Edx
);

After Uncristify
=================
AsmCpuidEx (
CPUID_EXTENDED_STATE,
CPUID_EXTENDED_STATE_SUB_LEAF,
&Eax.Uint32,
&Ebx,
&Ecx.Uint32,
&Edx
);

Here is the BZ on the topic.

https://bugzilla.tianocore.org/show_bug.cgi?id=714

I think you are suggesting that a 4th style may be allowed
which would be to support arguments in the same line as
the function name and additional arguments on additional
lines. Do you want to update this BZ with your additional
thoughts?


DEBUG macro parentheses
-----------------------
How does uncrustify treat DEBUG macros without this modification?
Do we start getting everything turned into multi-level indented
multi-line statements without this change?
I think this is related to the DEBUG() macro using double (( and double ))
parens.


Function pointer typedefs:
--------------------------
I don't see that function pointer typedefs need to rigidly follow the
same pattern as the declaration of functions implementing them. Could
we update the coding style (if needed) instead?
I know one issue with function pointer typedefs is making sure the format
is compatible with Doxygen document generation.

https://github.com/tianocore/edk2/tree/master/BaseTools/Scripts/PackageDocumentTools


Best Regards,

Leif

On Mon, Aug 16, 2021 at 16:00:38 -0400, Michael Kubacki wrote:
The edk2 branch was created here:
https://github.com/makubacki/edk2/tree/uncrustify_poc_2

We have a Project Mu fork with custom changes to the Uncrustify tool to help
comply with EDK II formatting here:
https://dev.azure.com/projectmu/_git/Uncrustify

The latest information about the status and how to experiment with the
configuration file and the tool are in that fork:
https://dev.azure.com/projectmu/Uncrustify/_wiki/wikis/Uncrustify.wiki/1/Project-Mu-(EDK-II)-Fork-Readme

That said, I have also finished a CI plugin to run Uncrustify that should be
ready soon to initially deploy in Project Mu. Before doing so, I am trying
to settle on an initial configuration file that less strictly but more
reliably formats the code than in the examples in those branches. For
example, remove heuristics that when run against the same set of code
multiple times can produce different results. An example would be a rule
that reformats code because it exceeds a specified column width on one run
but on the next run that reformatted code triggers a different rule to
further align the code and so on. At least initially, some rules might be
tweaked in a more conservative approach that can be tightened in the future.
Once this configuration file is ready, we will baseline Project Mu code as
an example and turn on the plugin. The CI plugin runs Uncrustify against
modified files and if there's any changes, indicating a formatting
deviation, the diff chunks are saved in a log so they can be viewed as a
build artifact.

I am making progress on the updated config file and I should be able to post
a "uncrustify_poc_3" branch soon with the results.

Regarding indentation, Marvin is right that Uncrustify cannot support edk2
indentation style out-of-box. Some changes are made in that fork to handle
the formatting. At this point, it can handle the indentation in the cases
I've seen. Uncrustify does potentially give us the ability to massively
deploy changes across the codebase in case a decision were made to change
the style.

Thanks,
Michael

On 8/16/2021 3:39 PM, Marvin Häuser wrote:
Hey Rebecca,

I think even Uncrustify has issues with the EDK II indentation style.
You might want to check the UEFI Talkbox Discord server, I had a brief
chat with Michael about it there. I don't think realistically any tool
supports EDK II's indentation style however, so I'd propose it is
changed. This could be for new submissions only, or actually the entire
codebase could be reformatted at once with a good tool setup. While this
screws with git blame, the (to my understanding) decided on CRLF -> LF
change does that anyway, so at least two evils could be dealt with in
one go really.

Best regards,
Marvin

On 16/08/2021 21:34, Rebecca Cran wrote:

cc devel@ .

On 8/16/21 1:33 PM, Rebecca Cran wrote:

I noticed a message on Twitter about an idea of using Uncrustify
for EDK2 instead of the ECC tool, and came across https://www.mail-
archive.com/search?l=devel@edk2.groups.io&q=subject:%22Re%5C%3A+%5C%5Bedk2%5C-
devel%5C%5D+TianoCore+Community+Meeting+Minutes+%5C-+2%5C%2F4%22&o=newest&f=1
.

I was wondering if there's been any progress on it that I could
check out?


Michael Kubacki: in that message, you said:

"I'm planning to put up a branch that we can use as a reference
for a conversation around uncrustify in the next couple of
weeks."


Did you end up creating that branch, and if so could you provide
a link to it please?


--
Rebecca Cran








Re: Progress on getting Uncrustify working for EDK2?

Michael Kubacki
 

Thanks Mike, I will look into that.

For others, I recently published an "uncrustify_poc_3" branch on my edk2 fork that demonstrates the latest set of results I've obtained with Uncrustify tool changes and the configuration file. Most of the edk2-specific issues have been mitigated and I was able to reach a steady state of formatting results after two runs against the edk2 code base.

The results are starting to trend toward what might be "acceptable".

I would note that the edk2 repository and, in particular, certain packages like MdePkg and MdeModulePkg will have less substantial changes than others as the coding style tends to be followed more consistently there relative to many other repos.

Here's a link to the branch:

https://github.com/makubacki/edk2/tree/uncrustify_poc_3

There's a version here that attempts to add missing file and function headers (same branch just with that commit at the top):

https://github.com/makubacki/edk2/tree/uncrustify_poc_3_with_headers

Here's an Uncrustify application PR that I'm currently using the executable from for testing (it is in the PR build artifacts):

https://dev.azure.com/projectmu/Uncrustify/_git/Uncrustify/pullrequest/24

I'm interested in the discussion around style changes though we might be able to get away with less of those now. I am working on this in between other work so I also appreciate anyone willing to help out in any way.

Thanks,
Michael

On 10/7/2021 12:34 PM, Kinney, Michael D wrote:
Hi Michael,
I am looking at your uncrustify_poc_3 branch, and I see an unexpected change
related to use of IN/OUT in a function declaration.
File: MdeModulePkg\Logo\Logo.c
Before Uncrustify
=================
EFI_STATUS
EFIAPI
GetImage (
IN EDKII_PLATFORM_LOGO_PROTOCOL *This,
IN OUT UINT32 *Instance,
OUT EFI_IMAGE_INPUT *Image,
OUT EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE *Attribute,
OUT INTN *OffsetX,
OUT INTN *OffsetY
)
After Uncrustify
================
GetImage (
IN EDKII_PLATFORM_LOGO_PROTOCOL *This,
IN OUT UINT32 *Instance,
OUT EFI_IMAGE_INPUT *Image,
OUT EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE *Attribute,
OUT INTN *OffsetX,
OUT INTN *OffsetY
)
It aligned the start of each parameter line with 2 space indent, but lost the
alignment of the parameter names and did not do 2 spaces between the parameter
type and parameter name.
Best regards,
Mike
----------------------------------------------------------
From: Andrew Fish <afish@apple.com>
Sent: Thursday, October 7, 2021 9:04 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>
Cc: Leif Lindholm <leif@nuviainc.com>; mikuback@linux.microsoft.com; Marvin Häuser <mhaeuser@posteo.de>; Rebecca Cran <rebecca@nuviainc.com>; Michael Kubacki <Michael.Kubacki@microsoft.com>; Bret Barkelew <Bret.Barkelew@microsoft.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Andrew Fish <afish@apple.com>
Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?
On the git-blame front we might be able to build a recipe that walks past the code style and line ending commits that would could add to an FAQ or Wiki.
For bonus points we could add a git command that does this. You can add a Python git command to the repo by adding a git-<commandName> script in the path. So we could add a Python git command that skips blame of any of the known Uncrustify or line ending type commits. Basically `git eblame` that works just like `git blame` but skips formatting changes.
I’m working on a git-pgrep that only greps files used by a given build, hopeful I’ll be able to contribute that soon. My co-works keep finding bugs so I’m not quite done.
Thanks,
Andrew Fish
On Oct 7, 2021, at 11:30 AM, Andrew Fish via http://groups.io <mailto:afish=apple.com@groups.io> wrote:
On Oct 7, 2021, at 6:48 AM, Leif Lindholm <mailto:leif@nuviainc.com> wrote:
Hi Michael,
Apologies, I've owed you a response (promised off-list) for a while
now.
First, let me say I hugely appreciate this effort. Apart from aligning
the codebase(s), this will reduce manual reviewing effort
substantially, as well as cutting down on number of rework cycles for
developers.
Looking at the changes to (well, the comments in) uncrustify, this
seems to be constrained to:
- Newline after '(' for multi-line function calls.
- Dealing with "(("/"))" for DEBUG macros.
- Function pointer typedefs:
 - typedef\nEFIAPI
 - closing parentheses indentation
I don't think I've made any secret over the years that I am not a
massive fan of the EDK2 coding style in general. So I think for any
of its quirks that are substantial enough that they require not just
custom configuration but actual new function added to existing code
conformance tools, this would be an excellent point to sanitise the
coding style instead.
Taking these in order:
Newline after '('
-----------------
I think we already reached a level of flexibility around this, where
we don't actually enforce this (or single argument per
line). Personally, I'd be happy to update the coding style as
required instead.
DEBUG macro parentheses
-----------------------
How does uncrustify treat DEBUG macros without this modification?
Do we start getting everything turned into multi-level indented
multi-line statements without this change?
Can we disable the rule that does not like the DEBUG macro? I seem to remember clang nags about some strange () usage, so maybe we would not lose that much?
Thanks,
Andrew Fish
Function pointer typedefs:
--------------------------
I don't see that function pointer typedefs need to rigidly follow the
same pattern as the declaration of functions implementing them. Could
we update the coding style (if needed) instead?
Best Regards,
Leif
On Mon, Aug 16, 2021 at 16:00:38 -0400, Michael Kubacki wrote:
The edk2 branch was created here:
https://github.com/makubacki/edk2/tree/uncrustify_poc_2
We have a Project Mu fork with custom changes to the Uncrustify tool to help
comply with EDK II formatting here:
https://dev.azure.com/projectmu/_git/Uncrustify
The latest information about the status and how to experiment with the
configuration file and the tool are in that fork: https://dev.azure.com/projectmu/Uncrustify/_wiki/wikis/Uncrustify.wiki/1/Project-Mu-(EDK-II)-Fork-Readme
That said, I have also finished a CI plugin to run Uncrustify that should be
ready soon to initially deploy in Project Mu. Before doing so, I am trying
to settle on an initial configuration file that less strictly but more
reliably formats the code than in the examples in those branches. For
example, remove heuristics that when run against the same set of code
multiple times can produce different results. An example would be a rule
that reformats code because it exceeds a specified column width on one run
but on the next run that reformatted code triggers a different rule to
further align the code and so on. At least initially, some rules might be
tweaked in a more conservative approach that can be tightened in the future.
Once this configuration file is ready, we will baseline Project Mu code as
an example and turn on the plugin. The CI plugin runs Uncrustify against
modified files and if there's any changes, indicating a formatting
deviation, the diff chunks are saved in a log so they can be viewed as a
build artifact.
I am making progress on the updated config file and I should be able to post
a "uncrustify_poc_3" branch soon with the results.
Regarding indentation, Marvin is right that Uncrustify cannot support edk2
indentation style out-of-box. Some changes are made in that fork to handle
the formatting. At this point, it can handle the indentation in the cases
I've seen. Uncrustify does potentially give us the ability to massively
deploy changes across the codebase in case a decision were made to change
the style.
Thanks,
Michael
On 8/16/2021 3:39 PM, Marvin Häuser wrote:
Hey Rebecca,
I think even Uncrustify has issues with the EDK II indentation style.
You might want to check the UEFI Talkbox Discord server, I had a brief
chat with Michael about it there. I don't think realistically any tool
supports EDK II's indentation style however, so I'd propose it is
changed. This could be for new submissions only, or actually the entire
codebase could be reformatted at once with a good tool setup. While this
screws with git blame, the (to my understanding) decided on CRLF -> LF
change does that anyway, so at least two evils could be dealt with in
one go really.
Best regards,
Marvin
On 16/08/2021 21:34, Rebecca Cran wrote:
cc devel@ .
On 8/16/21 1:33 PM, Rebecca Cran wrote:
I noticed a message on Twitter about an idea of using Uncrustify
for EDK2 instead of the ECC tool, and came across https://www.mail-archive.com/search?l=devel@edk2.groups.io&q=subject:%22Re%5C%3A+%5C%5Bedk2%5C-devel%5C%5D+TianoCore+Community+Meeting+Minutes+%5C-+2%5C%2F4%22&o=newest&f=1
.
I was wondering if there's been any progress on it that I could
check out?
Michael Kubacki: in that message, you said:
"I'm planning to put up a branch that we can use as a reference
for a conversation around uncrustify in the next couple of
weeks."
Did you end up creating that branch, and if so could you provide
a link to it please?
--
Rebecca Cran


Re: Progress on getting Uncrustify working for EDK2?

Michael D Kinney
 

Hi Michael,

I am looking at your uncrustify_poc_3 branch, and I see an unexpected change
related to use of IN/OUT in a function declaration.

File: MdeModulePkg\Logo\Logo.c

Before Uncrustify
=================
EFI_STATUS
EFIAPI
GetImage (
IN EDKII_PLATFORM_LOGO_PROTOCOL *This,
IN OUT UINT32 *Instance,
OUT EFI_IMAGE_INPUT *Image,
OUT EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE *Attribute,
OUT INTN *OffsetX,
OUT INTN *OffsetY
)

After Uncrustify
================
GetImage (
IN EDKII_PLATFORM_LOGO_PROTOCOL *This,
IN OUT UINT32 *Instance,
OUT EFI_IMAGE_INPUT *Image,
OUT EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE *Attribute,
OUT INTN *OffsetX,
OUT INTN *OffsetY
)

It aligned the start of each parameter line with 2 space indent, but lost the
alignment of the parameter names and did not do 2 spaces between the parameter
type and parameter name.

Best regards,

Mike

----------------------------------------------------------

From: Andrew Fish <afish@apple.com>
Sent: Thursday, October 7, 2021 9:04 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>
Cc: Leif Lindholm <leif@nuviainc.com>; mikuback@linux.microsoft.com; Marvin Häuser <mhaeuser@posteo.de>; Rebecca Cran <rebecca@nuviainc.com>; Michael Kubacki <Michael.Kubacki@microsoft.com>; Bret Barkelew <Bret.Barkelew@microsoft.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Andrew Fish <afish@apple.com>
Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?

On the git-blame front we might be able to build a recipe that walks past the code style and line ending commits that would could add to an FAQ or Wiki.

For bonus points we could add a git command that does this. You can add a Python git command to the repo by adding a git-<commandName> script in the path. So we could add a Python git command that skips blame of any of the known Uncrustify or line ending type commits. Basically `git eblame` that works just like `git blame` but skips formatting changes. 

I’m working on a git-pgrep that only greps files used by a given build, hopeful I’ll be able to contribute that soon. My co-works keep finding bugs so I’m not quite done.

Thanks,

Andrew Fish


On Oct 7, 2021, at 11:30 AM, Andrew Fish via http://groups.io <mailto:afish=apple.com@groups.io> wrote:




On Oct 7, 2021, at 6:48 AM, Leif Lindholm <mailto:leif@nuviainc.com> wrote:

Hi Michael,

Apologies, I've owed you a response (promised off-list) for a while
now.

First, let me say I hugely appreciate this effort. Apart from aligning
the codebase(s), this will reduce manual reviewing effort
substantially, as well as cutting down on number of rework cycles for
developers.

Looking at the changes to (well, the comments in) uncrustify, this
seems to be constrained to:
- Newline after '(' for multi-line function calls.
- Dealing with "(("/"))" for DEBUG macros.
- Function pointer typedefs:
 - typedef\nEFIAPI
 - closing parentheses indentation

I don't think I've made any secret over the years that I am not a
massive fan of the EDK2 coding style in general. So I think for any
of its quirks that are substantial enough that they require not just
custom configuration but actual new function added to existing code
conformance tools, this would be an excellent point to sanitise the
coding style instead.

Taking these in order:

Newline after '('
-----------------
I think we already reached a level of flexibility around this, where
we don't actually enforce this (or single argument per
line). Personally, I'd be happy to update the coding style as
required instead.

DEBUG macro parentheses
-----------------------
How does uncrustify treat DEBUG macros without this modification?
Do we start getting everything turned into multi-level indented
multi-line statements without this change?

Can we disable the rule that does not like the DEBUG macro? I seem to remember clang nags about some strange () usage, so maybe we would not lose that much?

Thanks,

Andrew Fish



Function pointer typedefs:
--------------------------
I don't see that function pointer typedefs need to rigidly follow the
same pattern as the declaration of functions implementing them. Could
we update the coding style (if needed) instead?

Best Regards,

Leif

On Mon, Aug 16, 2021 at 16:00:38 -0400, Michael Kubacki wrote:

The edk2 branch was created here:
https://github.com/makubacki/edk2/tree/uncrustify_poc_2

We have a Project Mu fork with custom changes to the Uncrustify tool to help
comply with EDK II formatting here:
https://dev.azure.com/projectmu/_git/Uncrustify

The latest information about the status and how to experiment with the
configuration file and the tool are in that fork: https://dev.azure.com/projectmu/Uncrustify/_wiki/wikis/Uncrustify.wiki/1/Project-Mu-(EDK-II)-Fork-Readme

That said, I have also finished a CI plugin to run Uncrustify that should be
ready soon to initially deploy in Project Mu. Before doing so, I am trying
to settle on an initial configuration file that less strictly but more
reliably formats the code than in the examples in those branches. For
example, remove heuristics that when run against the same set of code
multiple times can produce different results. An example would be a rule
that reformats code because it exceeds a specified column width on one run
but on the next run that reformatted code triggers a different rule to
further align the code and so on. At least initially, some rules might be
tweaked in a more conservative approach that can be tightened in the future.
Once this configuration file is ready, we will baseline Project Mu code as
an example and turn on the plugin. The CI plugin runs Uncrustify against
modified files and if there's any changes, indicating a formatting
deviation, the diff chunks are saved in a log so they can be viewed as a
build artifact.

I am making progress on the updated config file and I should be able to post
a "uncrustify_poc_3" branch soon with the results.

Regarding indentation, Marvin is right that Uncrustify cannot support edk2
indentation style out-of-box. Some changes are made in that fork to handle
the formatting. At this point, it can handle the indentation in the cases
I've seen. Uncrustify does potentially give us the ability to massively
deploy changes across the codebase in case a decision were made to change
the style.

Thanks,
Michael

On 8/16/2021 3:39 PM, Marvin Häuser wrote:

Hey Rebecca,

I think even Uncrustify has issues with the EDK II indentation style.
You might want to check the UEFI Talkbox Discord server, I had a brief
chat with Michael about it there. I don't think realistically any tool
supports EDK II's indentation style however, so I'd propose it is
changed. This could be for new submissions only, or actually the entire
codebase could be reformatted at once with a good tool setup. While this
screws with git blame, the (to my understanding) decided on CRLF -> LF
change does that anyway, so at least two evils could be dealt with in
one go really.

Best regards,
Marvin

On 16/08/2021 21:34, Rebecca Cran wrote:


cc devel@ .

On 8/16/21 1:33 PM, Rebecca Cran wrote:


I noticed a message on Twitter about an idea of using Uncrustify
for EDK2 instead of the ECC tool, and came across https://www.mail-archive.com/search?l=devel@edk2.groups.io&q=subject:%22Re%5C%3A+%5C%5Bedk2%5C-devel%5C%5D+TianoCore+Community+Meeting+Minutes+%5C-+2%5C%2F4%22&o=newest&f=1
.

I was wondering if there's been any progress on it that I could
check out?


Michael Kubacki: in that message, you said:

"I'm planning to put up a branch that we can use as a reference
for a conversation around uncrustify in the next couple of
weeks."


Did you end up creating that branch, and if so could you provide
a link to it please?


-- 
Rebecca Cran


Re: Progress on getting Uncrustify working for EDK2?

Marvin Häuser
 

Good day,

+1, but while you're at it, can we have arguments not align to the function name...

Status = Test (
a
);

... but to the next natural indentation level?

Status = Test (
a
);

Basically no IDE I have seen supports EDK II's style, and I wouldn't be keen on writing known-broken style to then rely on Uncrustify to fix it.

I also have heard some controversy regarding casts off-list, where some prefer no spaces after casts to stress the evaluation order, and some prefer spaces to have clearer visuals (as a cast *ideally* would be something rare that requires good justification). Just throwing that out there.


For things unrelated to autoformat (so semi-offtopic) but still relevant to the coding spec:

1. Allow STATIC functions (if the debugging concerns are still relevant, there could be another level of indirection, like RELEASE_STATIC)?

2. Allow variable assignments on definition (basically non-static CONST variables are banned...)?

3. Allow variable declarations at any scope (I had some nasty shadowing bugs before, probably prohibit shadowing with warnings)?

4. Require that exactly all function declarations and all function definitions with no prior declaration must be documented (first direction is enforcing docs, second is prohibiting doc duplication, I've seen them go out-of-sync plenty of times)?

The latter bunch would not require any autoformat rules or reformatation of existing code, but would be target only new submissions in my opinion. Thoughts?


Thanks for your efforts!

Best regards,
Marvin


Am 07.10.2021 um 12:48 schrieb Leif Lindholm:

Hi Michael,
Apologies, I've owed you a response (promised off-list) for a while
now.
First, let me say I hugely appreciate this effort. Apart from aligning
the codebase(s), this will reduce manual reviewing effort
substantially, as well as cutting down on number of rework cycles for
developers.
Looking at the changes to (well, the comments in) uncrustify, this
seems to be constrained to:
- Newline after '(' for multi-line function calls.
- Dealing with "(("/"))" for DEBUG macros.
- Function pointer typedefs:
- typedef\nEFIAPI
- closing parentheses indentation
I don't think I've made any secret over the years that I am not a
massive fan of the EDK2 coding style in general. So I think for any
of its quirks that are substantial enough that they require not just
custom configuration but actual new function added to existing code
conformance tools, this would be an excellent point to sanitise the
coding style instead.
Taking these in order:
Newline after '('
-----------------
I think we already reached a level of flexibility around this, where
we don't actually enforce this (or single argument per
line). Personally, I'd be happy to update the coding style as
required instead.
DEBUG macro parentheses
-----------------------
How does uncrustify treat DEBUG macros without this modification?
Do we start getting everything turned into multi-level indented
multi-line statements without this change?
Function pointer typedefs:
--------------------------
I don't see that function pointer typedefs need to rigidly follow the
same pattern as the declaration of functions implementing them. Could
we update the coding style (if needed) instead?
Best Regards,
Leif
On Mon, Aug 16, 2021 at 16:00:38 -0400, Michael Kubacki wrote:
The edk2 branch was created here:
https://github.com/makubacki/edk2/tree/uncrustify_poc_2

We have a Project Mu fork with custom changes to the Uncrustify tool to help
comply with EDK II formatting here:
https://dev.azure.com/projectmu/_git/Uncrustify

The latest information about the status and how to experiment with the
configuration file and the tool are in that fork: https://dev.azure.com/projectmu/Uncrustify/_wiki/wikis/Uncrustify.wiki/1/Project-Mu-(EDK-II)-Fork-Readme

That said, I have also finished a CI plugin to run Uncrustify that should be
ready soon to initially deploy in Project Mu. Before doing so, I am trying
to settle on an initial configuration file that less strictly but more
reliably formats the code than in the examples in those branches. For
example, remove heuristics that when run against the same set of code
multiple times can produce different results. An example would be a rule
that reformats code because it exceeds a specified column width on one run
but on the next run that reformatted code triggers a different rule to
further align the code and so on. At least initially, some rules might be
tweaked in a more conservative approach that can be tightened in the future.
Once this configuration file is ready, we will baseline Project Mu code as
an example and turn on the plugin. The CI plugin runs Uncrustify against
modified files and if there's any changes, indicating a formatting
deviation, the diff chunks are saved in a log so they can be viewed as a
build artifact.

I am making progress on the updated config file and I should be able to post
a "uncrustify_poc_3" branch soon with the results.

Regarding indentation, Marvin is right that Uncrustify cannot support edk2
indentation style out-of-box. Some changes are made in that fork to handle
the formatting. At this point, it can handle the indentation in the cases
I've seen. Uncrustify does potentially give us the ability to massively
deploy changes across the codebase in case a decision were made to change
the style.

Thanks,
Michael

On 8/16/2021 3:39 PM, Marvin Häuser wrote:
Hey Rebecca,

I think even Uncrustify has issues with the EDK II indentation style.
You might want to check the UEFI Talkbox Discord server, I had a brief
chat with Michael about it there. I don't think realistically any tool
supports EDK II's indentation style however, so I'd propose it is
changed. This could be for new submissions only, or actually the entire
codebase could be reformatted at once with a good tool setup. While this
screws with git blame, the (to my understanding) decided on CRLF -> LF
change does that anyway, so at least two evils could be dealt with in
one go really.

Best regards,
Marvin

On 16/08/2021 21:34, Rebecca Cran wrote:

cc devel@ .

On 8/16/21 1:33 PM, Rebecca Cran wrote:

I noticed a message on Twitter about an idea of using Uncrustify
for EDK2 instead of the ECC tool, and came across https://www.mail-archive.com/search?l=devel@edk2.groups.io&q=subject:%22Re%5C%3A+%5C%5Bedk2%5C-devel%5C%5D+TianoCore+Community+Meeting+Minutes+%5C-+2%5C%2F4%22&o=newest&f=1
.

I was wondering if there's been any progress on it that I could
check out?


Michael Kubacki: in that message, you said:

"I'm planning to put up a branch that we can use as a reference
for a conversation around uncrustify in the next couple of
weeks."


Did you end up creating that branch, and if so could you provide
a link to it please?


--
Rebecca Cran







Re: Progress on getting Uncrustify working for EDK2?

Andrew Fish
 

On the git-blame front we might be able to build a recipe that walks past the code style and line ending commits that would could add to an FAQ or Wiki.

For bonus points we could add a git command that does this. You can add a Python git command to the repo by adding a git-<commandName> script in the path. So we could add a Python git command that skips blame of any of the known Uncrustify or line ending type commits. Basically `git eblame` that works just like `git blame` but skips formatting changes. 

I’m working on a git-pgrep that only greps files used by a given build, hopeful I’ll be able to contribute that soon. My co-works keep finding bugs so I’m not quite done.

Thanks,

Andrew Fish

On Oct 7, 2021, at 11:30 AM, Andrew Fish via groups.io <afish@...> wrote:



On Oct 7, 2021, at 6:48 AM, Leif Lindholm <leif@...> wrote:

Hi Michael,

Apologies, I've owed you a response (promised off-list) for a while
now.

First, let me say I hugely appreciate this effort. Apart from aligning
the codebase(s), this will reduce manual reviewing effort
substantially, as well as cutting down on number of rework cycles for
developers.

Looking at the changes to (well, the comments in) uncrustify, this
seems to be constrained to:
- Newline after '(' for multi-line function calls.
- Dealing with "(("/"))" for DEBUG macros.
- Function pointer typedefs:
 - typedef\nEFIAPI
 - closing parentheses indentation

I don't think I've made any secret over the years that I am not a
massive fan of the EDK2 coding style in general. So I think for any
of its quirks that are substantial enough that they require not just
custom configuration but actual new function added to existing code
conformance tools, this would be an excellent point to sanitise the
coding style instead.

Taking these in order:

Newline after '('
-----------------
I think we already reached a level of flexibility around this, where
we don't actually enforce this (or single argument per
line). Personally, I'd be happy to update the coding style as
required instead.

DEBUG macro parentheses
-----------------------
How does uncrustify treat DEBUG macros without this modification?
Do we start getting everything turned into multi-level indented
multi-line statements without this change?

Can we disable the rule that does not like the DEBUG macro? I seem to remember clang nags about some strange () usage, so maybe we would not lose that much?

Thanks,

Andrew Fish


Function pointer typedefs:
--------------------------
I don't see that function pointer typedefs need to rigidly follow the
same pattern as the declaration of functions implementing them. Could
we update the coding style (if needed) instead?

Best Regards,

Leif

On Mon, Aug 16, 2021 at 16:00:38 -0400, Michael Kubacki wrote:
The edk2 branch was created here:
https://github.com/makubacki/edk2/tree/uncrustify_poc_2

We have a Project Mu fork with custom changes to the Uncrustify tool to help
comply with EDK II formatting here:
https://dev.azure.com/projectmu/_git/Uncrustify

The latest information about the status and how to experiment with the
configuration file and the tool are in that fork: https://dev.azure.com/projectmu/Uncrustify/_wiki/wikis/Uncrustify.wiki/1/Project-Mu-(EDK-II)-Fork-Readme

That said, I have also finished a CI plugin to run Uncrustify that should be
ready soon to initially deploy in Project Mu. Before doing so, I am trying
to settle on an initial configuration file that less strictly but more
reliably formats the code than in the examples in those branches. For
example, remove heuristics that when run against the same set of code
multiple times can produce different results. An example would be a rule
that reformats code because it exceeds a specified column width on one run
but on the next run that reformatted code triggers a different rule to
further align the code and so on. At least initially, some rules might be
tweaked in a more conservative approach that can be tightened in the future.
Once this configuration file is ready, we will baseline Project Mu code as
an example and turn on the plugin. The CI plugin runs Uncrustify against
modified files and if there's any changes, indicating a formatting
deviation, the diff chunks are saved in a log so they can be viewed as a
build artifact.

I am making progress on the updated config file and I should be able to post
a "uncrustify_poc_3" branch soon with the results.

Regarding indentation, Marvin is right that Uncrustify cannot support edk2
indentation style out-of-box. Some changes are made in that fork to handle
the formatting. At this point, it can handle the indentation in the cases
I've seen. Uncrustify does potentially give us the ability to massively
deploy changes across the codebase in case a decision were made to change
the style.

Thanks,
Michael

On 8/16/2021 3:39 PM, Marvin Häuser wrote:
Hey Rebecca,

I think even Uncrustify has issues with the EDK II indentation style.
You might want to check the UEFI Talkbox Discord server, I had a brief
chat with Michael about it there. I don't think realistically any tool
supports EDK II's indentation style however, so I'd propose it is
changed. This could be for new submissions only, or actually the entire
codebase could be reformatted at once with a good tool setup. While this
screws with git blame, the (to my understanding) decided on CRLF -> LF
change does that anyway, so at least two evils could be dealt with in
one go really.

Best regards,
Marvin

On 16/08/2021 21:34, Rebecca Cran wrote:

cc devel@ .

On 8/16/21 1:33 PM, Rebecca Cran wrote:

I noticed a message on Twitter about an idea of using Uncrustify
for EDK2 instead of the ECC tool, and came across https://www.mail-archive.com/search?l@...&q=subject:%22Re%5C%3A+%5C%5Bedk2%5C-devel%5C%5D+TianoCore+Community+Meeting+Minutes+%5C-+2%5C%2F4%22&o=newest&f=1
.

I was wondering if there's been any progress on it that I could
check out?


Michael Kubacki: in that message, you said:

"I'm planning to put up a branch that we can use as a reference
for a conversation around uncrustify in the next couple of
weeks."


Did you end up creating that branch, and if so could you provide
a link to it please?


-- 
Rebecca Cran

















4301 - 4320 of 85849