Re: [edk2] [PATCH V3 1/4] MdePkg|EmulatorPkg: Update comment for PcdDefaultTerminalType
Can you just split this into two patches? I think we should keep patches confined to updating a single module unless there is a technical reason to touch separate packages in a single patch. Or, I suppose if you are making the *exact* same change to more than 3 packages, I guess it seems a little silly to make separate patches. On 2015-07-15 19:09:45, Heyi Guo wrote: Update comment for PcdDefaultTerminalType, as a new terminal type TTYTERM has been added with type value of 4. The new type is NOT defined in UEFI SPEC v2.5. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Heyi Guo heyi@linaro.org In the commit message, you can Cc Andrew and I in the EmulatorPkg patch here, and git send-email will automatically add the Cc when sending the email. You can add Reviewed-by: Jordan Justen jordan.l.jus...@intel.com to the separate EmulatorPkg patch. -Jordan --- EmulatorPkg/EmulatorPkg.dsc | 2 +- MdePkg/MdePkg.dec | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc index e0c6161..dfcd476 100644 --- a/EmulatorPkg/EmulatorPkg.dsc +++ b/EmulatorPkg/EmulatorPkg.dsc @@ -228,7 +228,7 @@ gEmulatorPkgTokenSpaceGuid.PcdEmuCpuModel|LIntel(R) Processor Model gEmulatorPkgTokenSpaceGuid.PcdEmuCpuSpeed|L3000 - # 0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8 + # 0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8, 4-TTYTERM gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1 [PcdsDynamicDefault.common.DEFAULT] diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index bda6550..598a6d0 100644 --- a/MdePkg/MdePkg.dec +++ b/MdePkg/MdePkg.dec @@ -2012,8 +2012,9 @@ # 1 - VT100BR # 2 - VT100+BR # 3 - UTF8BR + # 4 - TTYTERM, NOT defined in UEFI SPECBR # @Prompt Default Terminal Type. - # @ValidRange 0x8001 | 0 - 3 + # @ValidRange 0x8001 | 0 - 4 gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|0|UINT8|0x0024 ## Error level for hardware recorder. -- 2.1.4 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] 1 day until new edk2-devel email list transition
There is about 1 day until the transition to the new edk2-devel list. To update git send-email, run this command in your edk2 tree: git config sendemail.to edk2-de...@lists.01.org To configure Outlook for sending plain-text email to the list, I think this page might be helpful: https://support.office.com/en-za/article/Change-the-message-format-to-HTML-Rich-Text-or-plain-text-d92bba10-7ed4-4413-a031-7a1559112d90#__toc269980630 To sign up for the new list, visit: https://lists.01.org/mailman/listinfo/edk2-devel -Jordan On 2015-07-14 15:25:01, Jordan Justen wrote: Just to pick a transition time, let's change over ~2 days from now. In various time zones: $ TZ='UTC' date -d @1437087600 Thu Jul 16 23:00:00 UTC 2015 $ TZ='America/Los_Angeles' date -d @1437087600 Thu Jul 16 16:00:00 PDT 2015 $ TZ='Asia/Shanghai' date -d @1437087600 Fri Jul 17 07:00:00 CST 2015 For your local time, try: $ date -d @1437087600 To subscribe to the new list: https://lists.01.org/mailman/listinfo/edk2-devel Let's try to not use the new list until then to let people have one last chance to subscribe. Shortly after the cut-off, we'll reject email sent to the old list. -Jordan -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] 1 day until new edk2-devel email list transition
On 2015-07-15 16:23:54, Carsey, Jaben wrote: Can we get the old list to auto-respond with some info? Yes. That is my plan. Similar to when we moved edk2-buildtools-devel to edk2-devel... (Hmm, I may need to update the buildtools list message too. :) -Jordan -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan Justen Sent: Wednesday, July 15, 2015 4:21 PM To: edk2-devel; edk2-de...@lists.01.org Subject: [edk2-devel] 1 day until new edk2-devel email list transition There is about 1 day until the transition to the new edk2-devel list. To update git send-email, run this command in your edk2 tree: git config sendemail.to edk2-de...@lists.01.org To configure Outlook for sending plain-text email to the list, I think this page might be helpful: https://support.office.com/en-za/article/Change-the-message-format-to- HTML-Rich-Text-or-plain-text-d92bba10-7ed4-4413-a031- 7a1559112d90#__toc269980630 To sign up for the new list, visit: https://lists.01.org/mailman/listinfo/edk2-devel -Jordan On 2015-07-14 15:25:01, Jordan Justen wrote: Just to pick a transition time, let's change over ~2 days from now. In various time zones: $ TZ='UTC' date -d @1437087600 Thu Jul 16 23:00:00 UTC 2015 $ TZ='America/Los_Angeles' date -d @1437087600 Thu Jul 16 16:00:00 PDT 2015 $ TZ='Asia/Shanghai' date -d @1437087600 Fri Jul 17 07:00:00 CST 2015 For your local time, try: $ date -d @1437087600 To subscribe to the new list: https://lists.01.org/mailman/listinfo/edk2-devel Let's try to not use the new list until then to let people have one last chance to subscribe. Shortly after the cut-off, we'll reject email sent to the old list. -Jordan ___ edk2-devel mailing list edk2-de...@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] MTRR setup in OVMF [was: PATCH v3 01/10 KVM: MMU: fix decoding cache type from MTRR]
On 2015-07-14 14:29:11, Laszlo Ersek wrote: On 07/14/15 23:15, Paolo Bonzini wrote: The long delay that Alex reported (for the case when all guest memory was set to UC up-front) is due to the fact that the SEC phase of OVMF decompresses an approximately 1712 KB sized, LZMA-compressed blob, to approx. 896 KB worth of PEI drivers and 8192 KB worth of DXE and UEFI drivers -- and this decompression is extremely memory-intensive. (When Jordan implemented that reset vector first, we saw similar performance degradation on AMD hosts (albeit not due to MTRR but due to page attributes). See https://github.com/tianocore/edk2/commit/98f378a7. I'm only mentioning it here because it makes me appreciate the current problem report.) Anyway, the reset vector's page table building is implemented in OvmfPkg/ResetVector/Ia32/PageTables64.asm. The decompression in SEC can be found in OvmfPkg/Sec/SecMain.c, function DecompressMemFvs(). Perhaps the OVMF reset vector should initialize the MTRRs for the BSP? That's an idea, yes, if someone feels sufficiently drawn to writing assembly. Maybe we can use MtrrLib in the SEC C code? -Jordan Complications: - the reset vector is specific to OvmfPkg only in the OvmfPkgX64.dsc build - it needs to be determined what memory to cover. I think SEC doesn't do any MMIO, so it should be enough to enable MTRRs and set the default type to writeback. Seems safe to me, off the top of my head (and testing could confirm / disprove quickly). In any case we're going to have to quirk it, because of the broken guests in the wild. Thanks. Laszlo -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] New edk2-devel email list transition
Just to pick a transition time, let's change over ~2 days from now. In various time zones: $ TZ='UTC' date -d @1437087600 Thu Jul 16 23:00:00 UTC 2015 $ TZ='America/Los_Angeles' date -d @1437087600 Thu Jul 16 16:00:00 PDT 2015 $ TZ='Asia/Shanghai' date -d @1437087600 Fri Jul 17 07:00:00 CST 2015 For your local time, try: $ date -d @1437087600 To subscribe to the new list: https://lists.01.org/mailman/listinfo/edk2-devel Let's try to not use the new list until then to let people have one last chance to subscribe. Shortly after the cut-off, we'll reject email sent to the old list. -Jordan Forwarded message from Jordan Justen (2015-07-06 11:48:48): On 2015-07-04 15:56:05, B Cran wrote: On May 4, 2015, at 2:21 PM, Peterson, Joe joe.peter...@intel.com wrote: Due to community feedback, a new mailing list is being set up to replace this one. The new list will be hosted on Lists.01.org and should be more stable and consistent than this one. The host has an opt-in policy and will not allow the current subscription list to be imported so you will need to subscribe yourself. The timing of the final conversion to the new list is still to be determined, but in the meantime you can sign up for the new list here: https://lists.01.org/mailman/listinfo/edk2 Please keep all relevant communications on this channel and do not use the new one for patches or questions yet. Feel free to post questions/comment/concerns to this current list. Stay tuned for more updates... A list of the content changes / improvement being worked can be found here:http://www.tianocore.org/news/2015/05/01/UnderConst.html Since it has been about 2 months since this was sent, I was wondering if there's any update regarding plans, timing etc.? Joe is out of the office currently, so I'm going to take over on this task. I plan to transition the list over the next week or two. (I'll send out a separate email with the details.) Note that compared to the original announcement the list has been renamed from edk2 to edk2-devel. https://lists.01.org/mailman/listinfo/edk2-devel -Jordan -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v3 21/23] OvmfPkg: PciHostBridgeDxe: shorten search for extra root buses
On 2015-07-08 02:20:45, Laszlo Ersek wrote:
//
+ // QEMU provides the number of extra root buses, shortening the
exhaustive
+ // search below. If there is no hint, the feature is missing.
+ //
+ Status = QemuFwCfgFindFile (etc/extra-pci-roots, FwCfgItem,
FwCfgSize);
+ if (EFI_ERROR (Status) || FwCfgSize != sizeof ExtraRootBridgesLeft) {
+ExtraRootBridgesLeft = 0;
If QemuFwCfgFindFile() doesn't find the fw_cfg file, then it returns
NOT_FOUND. That will set ExtraRootBridgesLeft to zero, and then:
+ } else {
+QemuFwCfgSelectItem (FwCfgItem);
+QemuFwCfgReadBytes (FwCfgSize, ExtraRootBridgesLeft);
+DEBUG ((EFI_D_INFO, %a: %Lu extra root buses reported by QEMU\n,
+ __FUNCTION__, ExtraRootBridgesLeft));
+ }
+
+ //
// The main root bus is always there.
//
LastRootBridgeNumber = 0;
@@ -247,7 +266,7 @@ InitializePciHostBridge (
// alive.
//
for (RootBridgeNumber = 1;
- RootBridgeNumber 256;
+ RootBridgeNumber 256 ExtraRootBridgesLeft 0;
this condition here will prevent the loop body from executing even once.
Ok. Yeah, that looks good.
20-21 Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v3 23/23] OvmfPkg: QemuBootOrderLib: recognize extra PCI root buses
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
On 2015-07-07 08:09:25, Laszlo Ersek wrote:
The OFW device path that QEMU exports in the bootorder fw_cfg file, for
a device that is plugged into the main PCI root bus, is:
/pci@i0cf8/...
Whereas the same device plugged into the N'th extra root bus results in:
/pci@i0cf8,N/pci-bridge@0/...
(N is in hex.)
Extend TranslatePciOfwNodes() so that it not assume a single PCI root;
instead it parse the extra root bus serial number if present, and resolve
it in the translation to the UEFI devpath fragment.
Note that the pci-bridge@0 node is a characteristic of QEMU's PXB
device. It reflects the actual emulated PCI hierarchy. We don't parse it
specifically in this patch, because it is automatically handled by the
bridge sequence translator added recently in SVN rev 17385 (git commit
feca17fa4b) -- OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of
PCI bridges.
The macro EXAMINED_OFW_NODES need not be raised from 6. The longest OFW
device paths that we wish to recognize under this new scheme comprise 5
nodes. The initial extra root bus OFW fragment, visible at the top,
takes up 2 nodes, after which the longest device-specific patterns (IDE
disk, IDE CD-ROM, ISA floppy, virtio-scsi disk) take 3 more nodes each.
Cc: Jordan Justen jordan.l.jus...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
Notes:
v3:
- updated to the most recently agreed upon OFW notation for extra root
buses
v2:
- new in v2
OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c | 152
1 file changed, 128 insertions(+), 24 deletions(-)
diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
index 276d675..2e96343 100644
--- a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
+++ b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
@@ -27,6 +27,7 @@
#include Guid/GlobalVariable.h
#include Guid/VirtioMmioTransport.h
+#include ExtraRootBusMap.h
/**
OpenFirmware to UEFI device path translation output buffer size in
CHAR16's.
@@ -556,6 +557,11 @@ ParseOfwNode (
@param[in] NumNodesNumber of elements in OfwNode.
+ @param[in] ExtraPciRoots An EXTRA_ROOT_BUS_MAP object created with
+ CreateExtraRootBusMap(), to be used for
+ translating positions of extra root buses to
+ bus numbers.
+
@param[out]Translated Destination array receiving the UEFI path
fragment, allocated by the caller. If the
return value differs from RETURN_SUCCESS,
its
@@ -576,16 +582,23 @@ ParseOfwNode (
@retval RETURN_UNSUPPORTED The array of OpenFirmware device nodes
can't
be translated in the current
implementation.
+ @retval RETURN_PROTOCOL_ERRORThe initial OpenFirmware node refers to an
+ extra PCI root bus (by serial number) that
+ is invalid according to ExtraPciRoots.
+
**/
STATIC
RETURN_STATUS
TranslatePciOfwNodes (
- IN CONST OFW_NODE *OfwNode,
- IN UINTN NumNodes,
- OUT CHAR16 *Translated,
- IN OUT UINTN *TranslatedSize
+ IN CONST OFW_NODE *OfwNode,
+ IN UINTNNumNodes,
+ IN CONST EXTRA_ROOT_BUS_MAP *ExtraPciRoots,
+ OUT CHAR16 *Translated,
+ IN OUT UINTN*TranslatedSize
)
{
+ UINT32 PciRoot;
+ CHAR8 *Comma;
UINTN FirstNonBridge;
CHAR16 Bridges[BRIDGE_TRANSLATION_OUTPUT_SIZE];
UINTN BridgesLen;
@@ -594,7 +607,17 @@ TranslatePciOfwNodes (
UINTN Written;
//
- // Get PCI device and optional PCI function. Assume a single PCI root.
+ // Resolve the PCI root bus number.
+ //
+ // The initial OFW node for the main root bus (ie. bus number 0) is:
+ //
+ // /pci@i0cf8
+ //
+ // For extra root buses, the initial OFW node is
+ //
+ // /pci@i0cf8,4
+ // ^
+ // root bus serial number (not PCI bus number)
//
if (NumNodes REQUIRED_PCI_OFW_NODES ||
!SubstringEq (OfwNode[0].DriverName, pci)
@@ -602,6 +625,35 @@ TranslatePciOfwNodes (
return RETURN_UNSUPPORTED;
}
+ PciRoot = 0;
+ Comma = ScanMem8 (OfwNode[0].UnitAddress.Ptr, OfwNode[0].UnitAddress.Len,
+',');
+ if (Comma != NULL) {
+SUBSTRING PciRootSerialSubString;
+UINT64PciRootSerial;
+
+//
+// Parse the root bus serial number from the unit address after the
comma.
+//
+PciRootSerialSubString.Ptr = Comma + 1;
+PciRootSerialSubString.Len = OfwNode[0
Re: [edk2] [PATCH v3 22/23] OvmfPkg: QemuBootOrderLib: introduce ExtraRootBusMap
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com On 2015-07-07 08:09:24, Laszlo Ersek wrote: SeaBIOS requires the OpenFirmware device paths exported in the bootorder fw-cfg file to refer to extra (PXB) root buses by their relative positions (in increasing bus number order) rather than by actual bus numbers. However, OVMF's PCI host bridge / root bridge driver creates PciRoot(UID) device path nodes for extra PCI root buses with UID=bus_nr, not position. (These ACPI devpath UID values must, and do, match the UID values exposed in QEMU's ACPI payload, generated for PXB root buses.) Therefore the boot order matching logic will have to map extra root bus positions to bus numbers. Add a small group of utility functions to help with that. Cc: Jordan Justen jordan.l.jus...@intel.com Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek ler...@redhat.com --- Notes: v2: - new in v2 OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf | 6 + OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.h| 40 +++ OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.c| 313 3 files changed, 359 insertions(+) diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf index e972ae9..1024328 100644 --- a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf +++ b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf @@ -32,6 +32,7 @@ [Defines] [Sources] QemuBootOrderLib.c + ExtraRootBusMap.c [Packages] MdePkg/MdePkg.dec @@ -49,6 +50,7 @@ [LibraryClasses] PrintLib DevicePathLib BaseMemoryLib + OrderedCollectionLib [Guids] gEfiGlobalVariableGuid @@ -60,3 +62,7 @@ [FeaturePcd] [Pcd] gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut + +[Protocols] + gEfiDevicePathProtocolGuid## CONSUMES + gEfiPciRootBridgeIoProtocolGuid ## CONSUMES diff --git a/OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.h b/OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.h new file mode 100644 index 000..e2dbc38 --- /dev/null +++ b/OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.h @@ -0,0 +1,40 @@ +/** @file + Map positions of extra PCI root buses to bus numbers. + + Copyright (C) 2015, Red Hat, Inc. + + This program and the accompanying materials are licensed and made available + under the terms and conditions of the BSD License which accompanies this + distribution. The full text of the license may be found at + http://opensource.org/licenses/bsd-license.php + + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, WITHOUT + WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. +**/ + +#ifndef __EXTRA_ROOT_BUS_MAP_H__ +#define __EXTRA_ROOT_BUS_MAP_H__ + +/** + Incomplete (opaque) data type implementing the map. +**/ +typedef struct EXTRA_ROOT_BUS_MAP_STRUCT EXTRA_ROOT_BUS_MAP; + +EFI_STATUS +CreateExtraRootBusMap ( + OUT EXTRA_ROOT_BUS_MAP **ExtraRootBusMap + ); + +VOID +DestroyExtraRootBusMap ( + IN EXTRA_ROOT_BUS_MAP *ExtraRootBusMap + ); + +EFI_STATUS +MapRootBusPosToBusNr ( + IN CONST EXTRA_ROOT_BUS_MAP *ExtraRootBusMap, + IN UINT64 RootBusPos, + OUT UINT32 *RootBusNr + ); + +#endif diff --git a/OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.c b/OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.c new file mode 100644 index 000..ec42214 --- /dev/null +++ b/OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.c @@ -0,0 +1,313 @@ +/** @file + Map positions of extra PCI root buses to bus numbers. + + Copyright (C) 2015, Red Hat, Inc. + + This program and the accompanying materials are licensed and made available + under the terms and conditions of the BSD License which accompanies this + distribution. The full text of the license may be found at + http://opensource.org/licenses/bsd-license.php + + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, WITHOUT + WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. +**/ + +#include Library/DebugLib.h +#include Library/DevicePathLib.h +#include Library/MemoryAllocationLib.h +#include Library/OrderedCollectionLib.h +#include Library/UefiBootServicesTableLib.h +#include Protocol/DevicePath.h +#include Protocol/PciRootBridgeIo.h + +#include ExtraRootBusMap.h + +// +// The BusNumbers field is an array with Count elements. The elements increase +// strictry monotonically. Zero is not an element (because the zero bus number +// belongs to the main root bus, never to an extra root bus). Offset N in the +// array maps the extra root bus with position (N+1) to its bus number (because +// the root bus with position 0 is always the main root bus, therefore we don't +// store it). +// +// If there are no extra root
Re: [edk2] [PATCH v2] NetworkPkg: Locate IpSec protocol on IP4/IP6 packet processing only if it is installed
Your subject line is too long. (86 characters)
NetworkPkg/Contributions.txt
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
On 2015-07-11 07:51:24, Samer El-Haj-Mahmoud wrote:
From: Sriram Subramanian srira...@hp.com
Modified the logic in Ip4Dxe and Ip6Dxe to not locate EFI_IPSEC2_PROTOCOL on
each message transmit/receive. Instead, register a callback in the drivers
entry points on the IpSec protocol installation, and process only if the
protocol is installed. This speeds up the network stacks when IpSec is not
installed since there is a penalty associated with searching the entire
handle database on each packet processing.
This commit message line it too long (414 characters.)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud samer.el-haj-mahm...@hp.com
Once again, consider Cc'ing the package owner here in the commit
message. (Then git send-email will automatically Cc them when sending
the patch.)
---
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c | 36 +
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.h | 4 +++
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Input.c | 7 +
NetworkPkg/Ip6Dxe/Ip6Driver.c | 38
+++
NetworkPkg/Ip6Dxe/Ip6Impl.h | 3 ++
NetworkPkg/Ip6Dxe/Ip6Input.c | 6
I think this probably should be 2 patches. At least one for
MdeModulePkg and one for NetworkPkg.
-Jordan
6 files changed, 94 insertions(+)
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
index 101390c..d70380f 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
@@ -2,6 +2,8 @@
The driver binding and service binding protocol for IP4 driver.
Copyright (c) 2005 - 2015, Intel Corporation. All rights reserved.BR
+(C) Copyright 2015 Hewlett-Packard Development Company, L.P.BR
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
which accompanies this distribution. The full text of the license may be
found at
@@ -23,6 +25,30 @@ EFI_DRIVER_BINDING_PROTOCOL gIp4DriverBinding = {
NULL
};
+BOOLEAN mIpSec2Installed = FALSE;
+
+/**
+ Callback function for IpSec2 Protocol install.
+
+ @param[in] Event Event whose notification function is being
invoked
+ @param[in] Context Pointer to the notification function's context
+
+**/
+VOID
+EFIAPI
+IpSec2InstalledCallback (
+ IN EFI_EVENT Event,
+ IN VOID *Context
+ )
+{
+ //
+ // Close the event so it does not get called again.
+ //
+ gBS-CloseEvent (Event);
+
+ mIpSec2Installed = TRUE;
+}
+
/**
This is the declaration of an EFI image entry point. This entry point is
the same for UEFI Applications, UEFI OS Loaders, and UEFI Drivers including
@@ -45,6 +71,16 @@ Ip4DriverEntryPoint (
IN EFI_SYSTEM_TABLE *SystemTable
)
{
+ VOID*Registration;
+
+ EfiCreateProtocolNotifyEvent (
+gEfiIpSec2ProtocolGuid,
+TPL_CALLBACK,
+IpSec2InstalledCallback,
+NULL,
+Registration
+);
+
return EfiLibInstallDriverBindingComponentName2 (
ImageHandle,
SystemTable,
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.h
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.h
index 84dfa80..48728e5 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.h
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.h
@@ -2,6 +2,8 @@
Ip4 internal functions and type defintions.
Copyright (c) 2005 - 2015, Intel Corporation. All rights reserved.BR
+(C) Copyright 2015 Hewlett-Packard Development Company, L.P.BR
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
which accompanies this distribution. The full text of the license may be
found at
@@ -388,4 +390,6 @@ Ip4FreeTxToken (
extern EFI_IPSEC2_PROTOCOL *mIpSec;
+extern BOOLEAN mIpSec2Installed;
+
#endif
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Input.c
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Input.c
index 38ad1c3..51ded68 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Input.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Input.c
@@ -2,6 +2,8 @@
IP4 input process.
Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.BR
+(C) Copyright 2015 Hewlett-Packard Development Company, L.P.BR
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
which accompanies this distribution. The full text of the license may be
found at
@@ -512,6 +514,11 @@ Ip4IpSecProcessPacket (
IP4_HEAD
Re: [edk2] [PATCH] BaseTools: Add support for nested !include in FDF and DSC files Also added code to detect include loops and enhanced error reporting for included files
Your subject line is too long. (151 characters)
BaseTools/Contributions.txt
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
Should this be 2 patches? ('Also added...')
On 2015-07-11 07:00:48, Samer El-Haj-Mahmoud wrote:
From: Cecil Sheng cecil.sh...@hp.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com
Consider Cc'ing the package owner here in the commit message:
Cc: Yingke D Liu yingke.d@intel.com
Package owners are documented in Maintainers.txt.
-Jordan
---
BaseTools/Source/Python/GenFds/FdfParser.py| 90
+++---
.../Source/Python/Workspace/MetaFileParser.py | 12 +--
2 files changed, 86 insertions(+), 16 deletions(-)
diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py
b/BaseTools/Source/Python/GenFds/FdfParser.py
index ffc54ab..e84bdb1 100644
--- a/BaseTools/Source/Python/GenFds/FdfParser.py
+++ b/BaseTools/Source/Python/GenFds/FdfParser.py
@@ -2,6 +2,7 @@
# parse FDF file
#
# Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.BR
+# (C) Copyright 2015 Hewlett-Packard Development Company, L.P.BR
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD
License
@@ -81,16 +82,31 @@ RegionSizeGuidPattern =
re.compile(\s*(?Pbase\w+\.\w+)\s*\|\s*(?Psize\w+\.\
RegionOffsetPcdPattern = re.compile(\s*(?Pbase\w+\.\w+)\s*$)
ShortcutPcdPattern =
re.compile(\s*\w+\s*=\s*(?Pvalue(?:0x|0X)?[a-fA-F0-9]+)\s*\|\s*(?Pname\w+\.\w+)\s*)
-IncludeFileList = []
+AllIncludeFileList = []
+
+# Get the closest parent
+def GetParentAtLine (Line):
+for Profile in AllIncludeFileList:
+if Profile.IsLineInFile(Line):
+return Profile
+return None
+
+# Check include loop
+def IsValidInclude (File, Line):
+for Profile in AllIncludeFileList:
+if Profile.IsLineInFile(Line) and Profile.FileName == File:
+return False
+
+return True
def GetRealFileLine (File, Line):
InsertedLines = 0
-for Profile in IncludeFileList:
-if Line = Profile.InsertStartLineNumber and Line
Profile.InsertStartLineNumber + Profile.InsertAdjust +
len(Profile.FileLinesList):
-return (Profile.FileName, Line - Profile.InsertStartLineNumber +
1)
-if Line = Profile.InsertStartLineNumber + Profile.InsertAdjust +
len(Profile.FileLinesList):
-InsertedLines += Profile.InsertAdjust +
len(Profile.FileLinesList)
+for Profile in AllIncludeFileList:
+if Profile.IsLineInFile(Line):
+return Profile.GetLineInFile(Line)
+elif Line = Profile.InsertStartLineNumber and Profile.Level == 1:
+ InsertedLines += Profile.GetTotalLines()
return (File, Line - InsertedLines)
@@ -111,6 +127,7 @@ class Warning (Exception):
FileLineTuple = GetRealFileLine(File, Line)
self.FileName = FileLineTuple[0]
self.LineNumber = FileLineTuple[1]
+self.OriginalLineNumber = Line
self.Message = Str
self.ToolName = 'FdfParser'
@@ -157,6 +174,38 @@ class IncludeFileProfile :
self.InsertStartLineNumber = None
self.InsertAdjust = 0
+self.IncludeFileList = []
+self.Level = 1 # first level include file
+
+def GetTotalLines(self):
+TotalLines = self.InsertAdjust + len(self.FileLinesList)
+
+for Profile in self.IncludeFileList:
+ TotalLines += Profile.GetTotalLines()
+
+return TotalLines
+
+def IsLineInFile(self, Line):
+if Line = self.InsertStartLineNumber and Line
self.InsertStartLineNumber + self.GetTotalLines():
+return True
+
+return False
+
+def GetLineInFile(self, Line):
+if not self.IsLineInFile (Line):
+return (self.FileName, -1)
+
+InsertedLines = self.InsertStartLineNumber
+
+for Profile in self.IncludeFileList:
+if Profile.IsLineInFile(Line):
+return Profile.GetLineInFile(Line)
+elif Line = Profile.InsertStartLineNumber:
+InsertedLines += Profile.GetTotalLines()
+
+return (self.FileName, Line - InsertedLines + 1)
+
+
## The FDF content class that used to record file data when parsing FDF
#
@@ -565,10 +614,12 @@ class FdfParser:
# @param selfThe object pointer
#
def PreprocessIncludeFile(self):
-
+ # nested include support
+Processed = False
while self.__GetNextToken():
if self.__Token == '!include':
+Processed = True
IncludeLine = self.CurrentLineNumber
IncludeOffset = self.CurrentOffsetWithinLine -
len('!include')
if not self.__GetNextToken():
@@ -612,12 +663,19 @@ class
Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables
On 2015-07-08 12:02:10, Laszlo Ersek wrote: It seems to follow that Intel should operate such a build farm. Based on how long we've been whining about this, I don't think it's going to happen any time soon. Intel has had such a build farm for years. It does usually catch these issues... after the fact. Even then it'll take some time for someone to see the issue and attempt to fix it. But, it is a lot more likely that someone that uses GCC will notice the build break and submit a patch way before that process completes. Similarly, if we break the MSVC build (this is a two way street), then it'll probably be found and patched fairly quickly. It could be that the move to git will make it more feasible to have a testing branch that could allow all patches to first be tested against all toolchains. But, personally I'm not really sure that a separate branch would be worth the hassle. -Jordan -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v3 3/7] EmulatorPkg: Remove Ip4ConfigDxe module from EmulatorPkg
When you send new versions of the patch series, can you not reply to the previous version? Then discussions for each version of the series can happen separately. (It also makes v3 get a little hidden in the old v1/v2 emails.) On 2015-07-09 00:24:34, Jiaxin Wu wrote: Version3 continue to update with a proper commit message. I guess you don't agree with my suggested format? v3: * Update with a proper commit message Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not support original Ip4Config Protocol, which is replace by Ip4Config2 Protocol integrated in Ip4Dxe driver(git commit 1f6729ff (SVN r17853)).Therefore we can remove Ip4ConfigDxe driver from this build. This commit message line is too long: https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu jiaxin...@intel.com I guess you Cc'd Andrew and I manually? If you add Cc: Jordan Justen jordan.l.jus...@intel.com to the commit message, then git send-email will automatically add the Cc's when sending the email. It can save a lot of time when you have multiple versions of the patch series. Anyway, I guess with the long commit message lines fixed, then patches 3 5 Reviewed-by: Jordan Justen jordan.l.jus...@intel.com --- EmulatorPkg/EmulatorPkg.dsc | 1 - EmulatorPkg/EmulatorPkg.fdf | 3 +-- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc index b16fcac..e0c6161 100644 --- a/EmulatorPkg/EmulatorPkg.dsc +++ b/EmulatorPkg/EmulatorPkg.dsc @@ -355,11 +355,10 @@ # Network stack drivers # MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf - MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf diff --git a/EmulatorPkg/EmulatorPkg.fdf b/EmulatorPkg/EmulatorPkg.fdf index 83b1de6..a002389 100644 --- a/EmulatorPkg/EmulatorPkg.fdf +++ b/EmulatorPkg/EmulatorPkg.fdf @@ -1,9 +1,9 @@ ## @file # This is Emulator FDF file with UEFI HII features enabled # -# Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.BR +# Copyright (c) 2008 - 2015, Intel Corporation. All rights reserved.BR # Portions copyright (c) 2009 - 2011, Apple Inc. All rights reserved.BR # # This program and the accompanying materials # are licensed and made available under the terms and conditions of the BSD License # which accompanies this distribution. The full text of the license may be found at @@ -194,11 +194,10 @@ INF MdeModulePkg/Application/HelloWorld/HelloWorld.inf INF EmulatorPkg/EmuSnpDxe/EmuSnpDxe.inf !endif INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf -INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf -- 1.9.5.msysgit.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] Avoid variable set but not used warning from GCC.
Patch subject doesn't contain a package/module prefix. I suggest:
OvmfPkg/QemuFwCfgLib: Avoid variable set but not used warning from GCC
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
On 2015-07-09 17:09:20, Bill Paul wrote:
The FileReserved variable in QemuFwCfgFindFile() is only used to skip
over the reserved field in file headers, which causes newer versions of
GCC to flag it with a variable set but not used warning (which is normally
not visible since as of right now these warnings are supressed). It's true
that the value read into FileReserved is never used, but this is
intentional. This patch adds a do-nothing reference to silence the
warning.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bill Paul wp...@windriver.com
You should add Cc's here (package owners are in Maintainers.txt):
Cc: Jordan Justen jordan.l.jus...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
---
OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
index 24424f8..573d90f 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
@@ -283,6 +283,7 @@ QemuFwCfgFindFile (
FileSize = QemuFwCfgRead32 ();
FileSelect = QemuFwCfgRead16 ();
FileReserved = QemuFwCfgRead16 ();
+(VOID) FileReserved; /* Force a do-nothing reference. */
We use '//' comments in code.
Coding Standards Spec, Section 5. 4.2 Internal Comments:
For internal code comments, use C++ style (//) comment lines.
Instead of this change, why not just remove the FileReserved variable
and change the code:
//
// Read 2 reserved bytes
//
QemuFwCfgRead16 ();
-Jordan
InternalQemuFwCfgReadBytes (sizeof (FName), FName);
if (AsciiStrCmp (Name, FName) == 0) {
--
1.8.0
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v3 3/7] EmulatorPkg: Remove Ip4ConfigDxe module from EmulatorPkg
On 2015-07-10 00:29:18, Wu, Jiaxin wrote: I agree your suggested format absolutely. Sorry for my missing any attention. I'm not Cc any maintainer manually. We should know that the Cc part maintainers in commit message will be ignored by edk2-devel if the maintainers already in edk2-devel mailing list. You mean edk2-devel will strip it? Maybe there is a list setting to look at. Anyway, I think the Cc will still go directly to the Cc'd addresses. So, if we want to send out the patch to someone personally, we must need to specify the maintainers with “--to xxx” in git bash. Fortunately for git, it support the script format, which also can help us save a lot of time when have multiple versions of the patch series. How does this work? Anyway, I'd still like to figure out if there are problems using the standard Cc method. -Jordan -Original Message- From: Justen, Jordan L Sent: Friday, July 10, 2015 2:48 PM To: Wu, Jiaxin; edk2-devel@lists.sourceforge.net; af...@apple.com Subject: Re: [PATCH v3 3/7] EmulatorPkg: Remove Ip4ConfigDxe module from EmulatorPkg When you send new versions of the patch series, can you not reply to the previous version? Then discussions for each version of the series can happen separately. (It also makes v3 get a little hidden in the old v1/v2 emails.) On 2015-07-09 00:24:34, Jiaxin Wu wrote: Version3 continue to update with a proper commit message. I guess you don't agree with my suggested format? v3: * Update with a proper commit message Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not support original Ip4Config Protocol, which is replace by Ip4Config2 Protocol integrated in Ip4Dxe driver(git commit 1f6729ff (SVN r17853)).Therefore we can remove Ip4ConfigDxe driver from this build. This commit message line is too long: https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu jiaxin...@intel.com I guess you Cc'd Andrew and I manually? If you add Cc: Jordan Justen jordan.l.jus...@intel.com to the commit message, then git send-email will automatically add the Cc's when sending the email. It can save a lot of time when you have multiple versions of the patch series. Anyway, I guess with the long commit message lines fixed, then patches 3 5 Reviewed-by: Jordan Justen jordan.l.jus...@intel.com --- EmulatorPkg/EmulatorPkg.dsc | 1 - EmulatorPkg/EmulatorPkg.fdf | 3 +-- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc index b16fcac..e0c6161 100644 --- a/EmulatorPkg/EmulatorPkg.dsc +++ b/EmulatorPkg/EmulatorPkg.dsc @@ -355,11 +355,10 @@ # Network stack drivers # MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf - MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf diff --git a/EmulatorPkg/EmulatorPkg.fdf b/EmulatorPkg/EmulatorPkg.fdf index 83b1de6..a002389 100644 --- a/EmulatorPkg/EmulatorPkg.fdf +++ b/EmulatorPkg/EmulatorPkg.fdf @@ -1,9 +1,9 @@ ## @file # This is Emulator FDF file with UEFI HII features enabled # -# Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.BR +# Copyright (c) 2008 - 2015, Intel Corporation. All rights +reserved.BR # Portions copyright (c) 2009 - 2011, Apple Inc. All rights reserved.BR # # This program and the accompanying materials # are licensed and made available under the terms and conditions of the BSD License # which accompanies this distribution. The full text of the license may be found at @@ -194,11 +194,10 @@ INF MdeModulePkg/Application/HelloWorld/HelloWorld.inf INF EmulatorPkg/EmuSnpDxe/EmuSnpDxe.inf !endif INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf -INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf -- 1.9.5.msysgit.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support
Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables
On 2015-07-08 19:31:09, Scott Duplichan wrote: Bruce Cran [mailto:br...@cran.org.uk] wrote: ]Sent: Wednesday, July 08, 2015 05:12 PM ]To: edk2-devel@lists.sourceforge.net ]Subject: Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables ] ]On Wed, Jul 08, 2015 at 10:43:38PM +0200, Laszlo Ersek wrote: ] ] I think it would make a difference if -flto *actually* worked, but from ] a quick google search, I think it either doesn't work with gcc-4.8 at ] all, *or* the edk2 build system would have to use FLTO-aware binutils ] and linker wrappers (or parameters). I have no clue how to set that up. ] So for now we'll have to stick with MDEPKG_NDEBUG I guess. ] ]I've been trying to get -flto working this week, but without success (yet!). ]I'm currently running into a problem of ld (built from source) apparently not ]knowing about the lto plugin (and passing the liblto.so file via -plugin causes ]an assert failure), but I'll keep trying. Last year I spent some time to get gcc -flto working properly with EDK2. At that time, the people here were busy with other things and there didn't seem to be a lot of interest in gcc link time optimization. So I never submitted a patch. Maybe it is time to revive this effort. Here is what I found: http://notabs.org/uefi/gcc-lto.htm So 6 conditions need to be met for ghcc link time optimization to work properly with EDK2: 1) Add -flto to the compile flags 2) Use gcc to launch ld instead of invoking ld directly 3) Include the compile flags on the link command line 4) Use gcc-ar in place of ar when building static libraries 5) Library code that resolves helper function calls generated by the compiler must be compiled without the -flto flag 6) These libraries must be prefixed with -Wl,-plugin-opt=-pass-through= on the link command line. A patch from late 2014 is here: http://sourceforge.net/projects/edk2developertoolsforwindows/files/Patches/Link%20Time%20Optimization/ BaseTools/Contributions.txt (Contributed-under...) If you don't submit it edk2-devel, and continue to follow up on it, then work can easily slip through the cracks. That said, I've spent a little time looking at your work, so it's not true that there was no interest. But, if you have something that is *actually working* for DuetPkg, EmulatorPkg and OvmfPkg, can you put together a patch series? I don't see how we can manage 5 6 with our current BaseTools. How did you manage it? Searching for 'pass-through' in your patch doesn't yield any results. Thanks, -Jordan -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] Avoid variable set but not used warning from GCC.
On 2015-07-10 00:18:15, Laszlo Ersek wrote:
Ooops :)
Apparently I was too quick to commit this, without waiting for your
review. Anyway, some comments:
On 07/10/15 09:05, Jordan Justen wrote:
Patch subject doesn't contain a package/module prefix. I suggest:
OvmfPkg/QemuFwCfgLib: Avoid variable set but not used warning from GCC
I fixed that up when committing.
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
On 2015-07-09 17:09:20, Bill Paul wrote:
The FileReserved variable in QemuFwCfgFindFile() is only used to skip
over the reserved field in file headers, which causes newer versions of
GCC to flag it with a variable set but not used warning (which is
normally
not visible since as of right now these warnings are supressed). It's true
that the value read into FileReserved is never used, but this is
intentional. This patch adds a do-nothing reference to silence the
warning.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bill Paul wp...@windriver.com
You should add Cc's here (package owners are in Maintainers.txt):
Cc: Jordan Justen jordan.l.jus...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
Agree, but ultimately both of us noticed the patch :)
---
OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
index 24424f8..573d90f 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
@@ -283,6 +283,7 @@ QemuFwCfgFindFile (
FileSize = QemuFwCfgRead32 ();
FileSelect = QemuFwCfgRead16 ();
FileReserved = QemuFwCfgRead16 ();
+(VOID) FileReserved; /* Force a do-nothing reference. */
We use '//' comments in code.
Coding Standards Spec, Section 5. 4.2 Internal Comments:
For internal code comments, use C++ style (//) comment lines.
Yes, I did not miss that,
Well, I guess you could have tweaked it youself rather than requiring
a repost. (Like the patch subject.)
but I thought this was really minor here, and
I was happy that Bill finally decided to submit a patch! :) I didn't
want to discourage further contributions from him by splitting hairs
*here* :)
Instead of this change, why not just remove the FileReserved variable
and change the code:
//
// Read 2 reserved bytes
//
QemuFwCfgRead16 ();
I named that option before, in a slightly different form:
(VOID) QemuFwCfgRead16 ();
Because, without the explicit cast to VOID, some compiler might complain
about the return value being ignored.
That can't be true. Is it?? I can't imagine any significantly sized C
code base would not generate that warning.
Just below this code in QemuFwCfgS3Enabled we ignore the returns from
QemuFwCfgSelectItem and QemuFwCfgReadBytes.
In any case, I called Bill's version (the one I ultimately committed
too) more readable, so if you disagree with that, then it's my fault.
Declare the variable, set it, then actively ignore it vs just not
having the variable...
-Jordan
If you'd like, you can update the style in the source and commit it at
once as a separate patch, and add my R-b immediately (based on the above).
Thanks
Laszlo
-Jordan
InternalQemuFwCfgReadBytes (sizeof (FName), FName);
if (AsciiStrCmp (Name, FName) == 0) {
--
1.8.0
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] Avoid variable set but not used warning from GCC.
On 2015-07-10 10:46:19, Bill Paul wrote: Of all the gin joints in all the towns in all the world, Jordan Justen had to walk into mine at 00:53:23 on Friday 10 July 2015 and say: On 2015-07-10 00:18:15, Laszlo Ersek wrote: Ooops :) Apparently I was too quick to commit this, without waiting for your review. Anyway, some comments: On 07/10/15 09:05, Jordan Justen wrote: Patch subject doesn't contain a package/module prefix. I suggest: OvmfPkg/QemuFwCfgLib: Avoid variable set but not used warning from GCC I fixed that up when committing. https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Fo rmat For the record, I searched for the patch submission rules, but I must not have specified the exact right search terms to bring up this page because I never saw it. I did read the Contributions.txt file, but the instructions it contains are not the same as what's on the URL shown above, and they don't place special emphasis on the module name. Also, neither document mentions that you must include a CC list of maintainers. Given that Laszlo asked for the patch in the first place, it did not occur to me this would be necessary. If you want all patches to adhere to a rigid pattern, every time, then I suggest you a) put the exact set of rules in a file in the top level of the source tree, with fully documented examples and/or b) include a script to generate the submissions that prompts the user to enter all required fields. Be aware too that not every project uses the exact same rules for patch submissions, so don't be surprised if new (or infrequent) contributors can't immediately decipher your particular secret handshake. True, but we are trying to follow some fairly common practices. You'd like us to just accept your contributions as is, and not provide any feedback? I don't think that review feedback amounts to a secret handshake. On 2015-07-09 17:09:20, Bill Paul wrote: The FileReserved variable in QemuFwCfgFindFile() is only used to skip over the reserved field in file headers, which causes newer versions of GCC to flag it with a variable set but not used warning (which is normally not visible since as of right now these warnings are supressed). It's true that the value read into FileReserved is never used, but this is intentional. This patch adds a do-nothing reference to silence the warning. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bill Paul wp...@windriver.com You should add Cc's here (package owners are in Maintainers.txt): Cc: Jordan Justen jordan.l.jus...@intel.com Cc: Laszlo Ersek ler...@redhat.com Agree, but ultimately both of us noticed the patch :) --- OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 1 + 1 file changed, 1 insertion(+) diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c index 24424f8..573d90f 100644 --- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c +++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c @@ -283,6 +283,7 @@ QemuFwCfgFindFile ( FileSize = QemuFwCfgRead32 (); FileSelect = QemuFwCfgRead16 (); FileReserved = QemuFwCfgRead16 (); +(VOID) FileReserved; /* Force a do-nothing reference. */ We use '//' comments in code. Coding Standards Spec, Section 5. 4.2 Internal Comments: For internal code comments, use C++ style (//) comment lines. Yes, I did not miss that, Well, I guess you could have tweaked it youself rather than requiring a repost. (Like the patch subject.) Let me be clear that it doesn't matter me what any coding convention says, it doesn't matter that the C spec allows it, and it doesn't matter to me how many might advocate it, what arguments they put forth to support it or in how much esteem they are held: I will never, ever, EVER use C++-style comments in C code. You shouldn't expect a project to be receptive to your contributions if you are hostile towards its coding standards. What would be your reaction if someone submitted a patch to your project with c++ comments in a C file? I would think it is more constructive to try to open a discussion on having the coding standards changed. but I thought this was really minor here, and I was happy that Bill finally decided to submit a patch! :) I didn't want to discourage further contributions from him by splitting hairs *here* :) Instead of this change, why not just remove the FileReserved variable and change the code: // // Read 2 reserved bytes // QemuFwCfgRead16 (); I named that option before, in a slightly different form: (VOID) QemuFwCfgRead16 (); Because, without the explicit cast to VOID, some compiler might complain
Re: [edk2] [PATCH v3 3/7] EmulatorPkg: Remove Ip4ConfigDxe module from EmulatorPkg
On 2015-07-10 04:29:11, Laszlo Ersek wrote: On 07/10/15 10:40, Wu, Jiaxin wrote: Yes, edk2-devel will strip it. You can check version2 for those series patches, I had added someone with cc tag to the commit message, but it haven't actually cc to those people. (3) Laszlo will get a copy directly from you, and another copy *reflected* from the mailing list server. (Laszlo has mail filters in place that file the direct copy into his INBOX, and the reflected copy into his edk2-devel folder.) The copy that Laszlo directly gets from Jiaxin will have the following headers: From: Jiaxin To: edk2-devel Cc: Laszlo The copy that Laszlo gets from the mailing list server will have the following headers: From: Jiaxin To: edk2-devel This is because the mailing list server is *stupid*. It sees, in its internal database, that Laszlo is subscribed, and therefore thinks (completely incorrectly) that Laszlo should not be Cc:-d on messages reflected from the list, because he gets them anyway. I found that mailman has a 'nodupes' setting that causes the Cc stripping. I've disabled it for the new edk2-devel list. Hopefully that is the setting we want... Unfortunately, disabling it on the current list would be a hassle. -Jordan -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] Trivial patch process?
Fork a new thread from the BaseTools/GCC: allow unused but set variables thread... Forwarded message from Laszlo Ersek (2015-07-08 21:56:36): On 07/09/15 01:42, Jordan Justen wrote: What about a lower bar for committing build break fixes? What if we said that compiler warning fixes could be committed by any package maintainer for any package as long as it is an obvious trivial fix and it has at least one r-b? That sounds pretty good to me! I think qemu has a 'trivial' patch process. I can't remember the details, but it may involve just Cc'ing the list with a different name. Like: Cc: edk2-trivial edk2-devel@lists.sourceforge.net http://wiki.qemu.org/Contribute/TrivialPatches I see they have a separate email list. I prefer to leverage the edk2-devel list but use the alternate name field in the Cc. I've seen another project use the main email list address, but alter the name to ping stable branches. So, for example, we could also consider: Cc: UDK2014.SP1 edk2-devel@lists.sourceforge.net These can still be searched for, but don't require the hassle of a separate email list. :) Anyway, I don't really support this build flag change, but I suppose it could be acceptable for RELEASE builds. I think Ard abandoned the idea on seeing Olivier's followup, and I did the same when I saw Bill's answer. Your idea about streamlining the current fixup process is a good one; let's adopt it. Does it need to be codified somewhere (Maintainers.txt, Contributions.txt, ...)? I would say Maintainers.txt since it documents email addresses. However, it might also want to list to a web page that explains it in more detail. I think we should hold off on it until we move to the new email list, but maybe we can figure out a plan that sounds reasonable now. -Jordan -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] OvmfPkg: Fix the build.sh shebang line to avoid depending on location of bash
On 2015-07-08 00:09:40, Bruce Cran wrote: On Tue, Jul 07, 2015 at 09:32:39PM -0700, Jordan Justen wrote: Reviewed-by: Jordan Justen jordan.l.jus...@intel.com Could it be committed to the UDK2014.SP1 branch as well as master, please? Bruce, I'm not sure of the update process for that branch, but it sure seems like a non-risky patch to cherry-pick. Hot, Liming, Do either of you know who owns the UDK2014.SP1 branch? Thanks, -Jordan -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v2 1/7] MdeModulePkg: Remove Ip4ConfigDxe module and related guid definition from MdeModulePkg.
I think the period (.) at the end of the commit message just wastes a
valuable subject line character. :) Your subject line is 87
characters, and I think the recommendation is for 70 characters or
less.
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
On 2015-07-07 23:24:29, jiaxinwu wrote:
Version2 update with a proper commit message.
It seems like this format is usually (or often) used. But, we've never
documented it for EDK II...
v2:
* Update commit message
Cc: Feng Tian feng.t...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: jiaxinwu jiaxin...@intel.com
Can you set your git config user.name setting?
https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup
This will make git commit -s produce a better Signed-off-by.
I don't think the current patches match the requirement for
Signed-off-by documented in MdeModulePkg/Contributions.txt.
---
MdeModulePkg/Include/Guid/Ip4ConfigHii.h | 25 -
MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h | 70 --
MdeModulePkg/MdeModulePkg.dec | 6 -
MdeModulePkg/MdeModulePkg.dsc | 1 -
.../Universal/Network/Ip4ConfigDxe/ComponentName.c | 165
.../Universal/Network/Ip4ConfigDxe/Ip4Config.c | 745 -
.../Universal/Network/Ip4ConfigDxe/Ip4Config.h | 533
.../Network/Ip4ConfigDxe/Ip4ConfigDriver.c | 505
.../Network/Ip4ConfigDxe/Ip4ConfigDxe.inf | 91 ---
.../Network/Ip4ConfigDxe/Ip4ConfigDxe.uni | Bin 2700 - 0 bytes
.../Network/Ip4ConfigDxe/Ip4ConfigDxe.vfr | 89 --
.../Network/Ip4ConfigDxe/Ip4ConfigDxeExtra.uni | Bin 1366 - 0 bytes
.../Network/Ip4ConfigDxe/Ip4ConfigDxeStrings.uni | Bin 3000 - 0 bytes
.../Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.c | 909
-
.../Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.h | 54 --
.../Universal/Network/Ip4ConfigDxe/Ip4NvData.h | 48 --
.../Network/Ip4ConfigDxe/NicIp4Variable.c | 319
.../Network/Ip4ConfigDxe/NicIp4Variable.h | 104 ---
18 files changed, 3664 deletions(-)
delete mode 100644 MdeModulePkg/Include/Guid/Ip4ConfigHii.h
delete mode 100644 MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h
delete mode 100644
MdeModulePkg/Universal/Network/Ip4ConfigDxe/ComponentName.c
delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4Config.c
delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4Config.h
delete mode 100644
MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDriver.c
delete mode 100644
MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
delete mode 100644
MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.uni
delete mode 100644
MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.vfr
delete mode 100644
MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxeExtra.uni
delete mode 100644
MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxeStrings.uni
delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.c
delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.h
delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4NvData.h
delete mode 100644
MdeModulePkg/Universal/Network/Ip4ConfigDxe/NicIp4Variable.c
delete mode 100644
MdeModulePkg/Universal/Network/Ip4ConfigDxe/NicIp4Variable.h
diff --git a/MdeModulePkg/Include/Guid/Ip4ConfigHii.h
b/MdeModulePkg/Include/Guid/Ip4ConfigHii.h
deleted file mode 100644
index 87c54a0..000
--- a/MdeModulePkg/Include/Guid/Ip4ConfigHii.h
+++ /dev/null
@@ -1,25 +0,0 @@
-/** @file
- GUIDs used as HII FormSet and HII Package list GUID in Ip4ConfigDxe
driver.
-
-Copyright (c) 2011, Intel Corporation. All rights reserved.BR
-This program and the accompanying materials are licensed and made available
under
-the terms and conditions of the BSD License that accompanies this
distribution.
-The full text of the license may be found at
-http://opensource.org/licenses/bsd-license.php.
-
-THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
-WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#ifndef __IP4_CONFIG_HII_GUID_H__
-#define __IP4_CONFIG_HII_GUID_H__
-
-#define EFI_NIC_IP4_CONFIG_NVDATA_GUID \
- { \
-0x9d5b53f, 0xf4b0, 0x4f59, { 0xa0, 0xb1, 0x7b, 0x57, 0xd3, 0x5c, 0xe,
0x5 } \
- }
-
-extern EFI_GUID gNicIp4ConfigNvDataGuid;
-
-#endif
diff --git a/MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h
b/MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h
deleted file mode 100644
index d3ce76f..000
--- a/MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h
+++ /dev/null
@@ -1,70 +0,0 @@
-/** @file
- This file defines NIC_IP4_CONFIG_INFO structure.
-
-Copyright (c) 2009
Re: [edk2] [PATCH 1/2] SecurityPkg: Refine the function comments.
Regarding the commit message, how about: === SecurityPkg/Pkcs7VerifyDxe: Cleanup P7CheckTrust function comments The comments for P7CheckTrust described Content and ContentSize parameters, but they don't exist. === With the updated commit message: Reviewed-by: Jordan Justen jordan.l.jus...@intel.com On 2015-07-07 01:41:36, Qiu Shumin wrote: Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qiu Shumin shumin@intel.com CC: Long, Qin qin.l...@intel.com Did this Cc work with git send-email? I always worry when the comma (,) is used in the name. Usually it is written as: Cc: Qin Long qin.l...@intel.com But, it might also work if you add quotes around the name: Cc: Long, Qin qin.l...@intel.com -Jordan --- SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c b/SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c index 6319255..13c9138 100644 --- a/SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c +++ b/SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c @@ -619,12 +619,6 @@ _Exit: @param[in] AllowedDb Pointer to a list of pointers to EFI_SIGNATURE_LIST structures which contains lists of X.509 certificates of approved signers. - @param[out] Content An optional caller-allocated buffer into which the - function will copy the content of PKCS7 signedData. - @param[in,out] ContentSize On input, points of the size in bytes of the optional - buffer Content previously allocated by caller. On output, - the value will contain the actual size of the content - extracted from the signedData. @retval EFI_SUCCESS The PKCS7 signedData is trusted. @retval EFI_SECURITY_VIOLATION Fail to verify the signature in PKCS7 signedData. -- 1.9.5.msysgit.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables
On 2015-07-08 08:58:04, Laszlo Ersek wrote:
On 07/08/15 17:02, Ard Biesheuvel wrote:
On 8 July 2015 at 16:59, Olivier Martin olivier.mar...@arm.com wrote:
For ARM architectures, I only disable this flag for RELEASE build:
OK, I hadn't noticed that. This means my patch would be only for the
convenience of the Intel engineers (and my peace of mind as operator
of a Jenkins job that gets broken all the time :-)) since the other
use case I described is already covered by these.
So please disregard my patch then.
I think your idea is good. For RELEASE builds, the valid pattern you
described should be kept working, but for DEBUG and NOOPT builds, the
warning should be emitted and it should also break the build. It's
regrettable that it's always us having to report / clean up after the
Intel developers working with MSVC, but ultimately it leads to a tidier
code base.
What is the use case? Someone has a regular build pool that *only*
does RELEASE builds?
I think nearly all automated build systems will also do DEBUG builds,
and thus will still see the build error.
What about a lower bar for committing build break fixes? What if we
said that compiler warning fixes could be committed by any package
maintainer for any package as long as it is an obvious trivial fix and
it has at least one r-b?
I think qemu has a 'trivial' patch process. I can't remember the
details, but it may involve just Cc'ing the list with a different
name. Like:
Cc: edk2-trivial edk2-devel@lists.sourceforge.net
Anyway, I don't really support this build flag change, but I suppose
it could be acceptable for RELEASE builds.
-Jordan
(Perhaps NOOPT should be handled similarly to RELEASE, and not DEBUG. In
that case I should update the patch I attached to my other email. We
don't really use NOOPT with gcc at all, so I included it in my patch
only for completeness.)
Thanks
Laszlo
$ grep -r unused-but-set-variable Conf/tools_def.txt
DEFINE GCC46_IA32_CC_FLAGS = DEF(GCC45_IA32_CC_FLAGS)
-Wno-address -Wno-unused-but-set-variable
DEFINE GCC46_X64_CC_FLAGS= DEF(GCC45_X64_CC_FLAGS)
-Wno-address -Wno-unused-but-set-variable
RELEASE_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS)
-Wno-unused-but-set-variable
RELEASE_GCC47_ARM_CC_FLAGS = DEF(GCC47_ARM_CC_FLAGS)
-Wno-unused-but-set-variable
RELEASE_GCC47_AARCH64_CC_FLAGS = DEF(GCC47_AARCH64_CC_FLAGS)
-Wno-unused-but-set-variable
RELEASE_GCC48_ARM_CC_FLAGS = DEF(GCC48_ARM_CC_FLAGS)
-Wno-unused-but-set-variable
RELEASE_GCC48_AARCH64_CC_FLAGS = DEF(GCC48_AARCH64_CC_FLAGS)
-Wno-unused-but-set-variable
RELEASE_GCC49_ARM_CC_FLAGS = DEF(GCC49_ARM_CC_FLAGS)
-Wno-unused-but-set-variable
RELEASE_GCC49_AARCH64_CC_FLAGS = DEF(GCC49_AARCH64_CC_FLAGS)
-Wno-unused-but-set-variable
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 08 July 2015 14:24
To: edk2-devel@lists.sourceforge.net; ler...@redhat.com; Olivier Martin;
leif.lindh...@linaro.org; jordan.l.jus...@intel.com
Cc: roy.fr...@linaro.org; Ard Biesheuvel
Subject: [PATCH] BaseTools/GCC: allow unused but set variables
This fixes a recurring problem where patches that have only been tested on
MS toolchains break the build on GCC because they use variables that are
only written but never read.
However, there is a valid pattern where this may happen as well.
For instance,
Status = SomeFunc (OutVar);
ASSERT_EFI_ERROR (Status);
if (Outvar == ... ) { ... }
// Status never referenced again
may never access Status again at all in RELEASE builds, since the
ASSERT_EFI_ERROR () macro evaluates to nothing in that case.
So let's allow this pattern, by passing the appropriate GCC command line
option.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
BaseTools/Conf/tools_def.template | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/BaseTools/Conf/tools_def.template
b/BaseTools/Conf/tools_def.template
index 7edd7590956b..15d8db04232f 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3813,7 +3813,7 @@ NOOPT_DDK3790xASL_IPF_DLINK_FLAGS= /NOLOGO
/NODEFAULTLIB /LTCG /DLL /OPT:REF
DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG =
--add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG =
-DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar
-fno-strict-aliasing -Wall -Werror -Wno-array-bounds -c -include AutoGen.h
+DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar
-fno-strict-aliasing -Wall -Werror -Wno-array-bounds -c -include AutoGen.h
-Wno-error=unused-but-set-variable
DEFINE GCC_IA32_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS) -m32
-malign-double -freorder-blocks -freorder-blocks-and-partition -O2
-mno-stack-arg-probe
Re: [edk2] [PATCH v3 20/23] OvmfPkg: PciHostBridgeDxe: look for all root buses
On 2015-07-07 08:09:22, Laszlo Ersek wrote:
In this patch we assume that root bus number 0 is always there (same as
before), and scan the rest of the extra root buses, up to and including
255. When an extra root bus is found, we install the PCI root bridge IO
protocol for the previous root bus (which might be bus 0 or just the
previous extra root bus).
The root bridge protocol created thus will report the available bus number
range
[own bus number, next extra root bus number - 1]
The LHS of this interval will be used for the root bus's own number, and
the rest of the interval (which might encompass 0 additional elements too)
can be used by the PCI bus driver to assign subordinate bus numbers from.
(Subordinate buses are provided by PCI bridges that hang off the root bus
in question.)
For MMIO and IO space allocation, all the root buses share the original
[0x8000_, 0x_] and [0x0, 0x] ranges, respectively.
Cc: Jordan Justen jordan.l.jus...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
Regression-tested-by: Gabriel Somlo so...@cmu.edu
---
OvmfPkg/PciHostBridgeDxe/PciHostBridge.c | 95 +++-
1 file changed, 71 insertions(+), 24 deletions(-)
diff --git a/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
b/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
index 7dda75f..3486644 100644
--- a/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
+++ b/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
@@ -43,14 +43,6 @@ EFI_PCI_ROOT_BRIDGE_DEVICE_PATH
mRootBridgeDevicePathTemplate = {
}
};
-//
-// Hard code: Root Bridge's resource aperture
-//
-
-PCI_ROOT_BRIDGE_RESOURCE_APERTURE mResAperture[1] = {
- {0, 0xff, 0x8000, 0x, 0, 0x}
-};
-
EFI_HANDLE mDriverImageHandle;
PCI_HOST_BRIDGE_INSTANCE mPciHostBridgeInstanceTemplate = {
@@ -80,8 +72,15 @@ PCI_HOST_BRIDGE_INSTANCE mPciHostBridgeInstanceTemplate = {
param[in] RootBusNumber The bus number of the root bus (root bridge)
to
create.
- RootBusNumber is expected to fall into the
valid
- offset range of mResAperture.
+
+ param[in] MaxSubBusNumber The inclusive maximum bus number that can be
+ assigned to any subordinate bus found behind
any
+ PCI bridge hanging off this root bus.
+
+ The caller is repsonsible for ensuring that
+ RootBusNumber = MaxSubBusNumber. If
+ RootBusNumber equals MaxSubBusNumber, then the
+ root bus has no room for subordinate buses.
param[in] HostBridgeHandle The EFI_HANDLE corresponding to the host
bridge
that is the parent of the root bridge to
create.
@@ -108,12 +107,16 @@ STATIC
EFI_STATUS
InitRootBridge (
IN UINT8RootBusNumber,
+ IN UINT8MaxSubBusNumber,
IN EFI_HANDLE HostBridgeHandle,
OUT PCI_ROOT_BRIDGE_INSTANCE **RootBus
)
{
- PCI_ROOT_BRIDGE_INSTANCE *PrivateData;
- EFI_STATUS Status;
+ PCI_ROOT_BRIDGE_INSTANCE *PrivateData;
+ PCI_ROOT_BRIDGE_RESOURCE_APERTURE ResAperture;
+ EFI_STATUSStatus;
+
+ ASSERT (RootBusNumber = MaxSubBusNumber);
PrivateData = AllocateZeroPool (sizeof *PrivateData);
if (PrivateData == NULL) {
@@ -126,13 +129,18 @@ InitRootBridge (
sizeof mRootBridgeDevicePathTemplate);
PrivateData-DevicePath.AcpiDevicePath.UID = RootBusNumber;
+ ResAperture.BusBase = RootBusNumber;
+ ResAperture.BusLimit = MaxSubBusNumber;
+ ResAperture.MemBase = BASE_2GB;
+ ResAperture.MemLimit = BASE_4GB - 1;
+ ResAperture.IoBase = 0;
+ ResAperture.IoLimit = MAX_UINT16;
//
// The function call below allocates no resources and performs no actions
// that have to be rolled back on later failure. It always succeeds.
//
Status = RootBridgeConstructor (PrivateData-Io, HostBridgeHandle,
- EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM,
- mResAperture[RootBusNumber]);
+ EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM, ResAperture);
ASSERT_EFI_ERROR (Status);
Status = gBS-InstallMultipleProtocolInterfaces (PrivateData-Handle,
@@ -143,6 +151,9 @@ InitRootBridge (
goto FreePrivateData;
}
+ DEBUG ((EFI_D_INFO,
+%a: installed root bus %d, with room for %d subordinate bus(es)\n,
+__FUNCTION__, RootBusNumber, MaxSubBusNumber - RootBusNumber));
*RootBus = PrivateData;
return EFI_SUCCESS;
@@ -196,6 +207,7 @@ InitializePciHostBridge (
)
{
EFI_STATUS Status;
+ UINTN LastRootBridgeNumber;
UINTN RootBridgeNumber
Re: [edk2] [PATCH v2 02/24] PcAtChipsetPkg: remove PciHostBridgeDxe
On 2015-07-06 19:25:37, Ni, Ruiyu wrote: Jordan, Laszlo, I personally strongly disagree using PCD to split code to make the code common. Well, at least a definitive statement. :) Previously you did not seem to have much of an opinion on it: Simply using PCD to split the code is very straightforward. Another approach is to introduce a new library class with carefully defined library APIs so that different platforms can use one common driver plus different instances of libraries. I'm really doubtful that a library class will ever be developed to allow OVMF to return to using the PcAtChipsetPkg version of the driver. I guess we will leave PcAtChipsetPkg/PciHostBridgeDxe to you and all those closed source platforms. I still hope you'll look into it more and consider deleting PcAtChipsetPkg/PciHostBridgeDxe if no one is actually using it. Thanks, -Jordan PCD is a very fashion word in EDKII world but most of the time it downgrades to C macro. Do you think one piece of common code heavily using macro is better than two pieces of code? I doubt that! So unless someone (either you or Laszlo) can propose a better solution to generalize the code, I would prefer to duplicate the code in OvmfPkg first. From the view of core packages, there is no change. From OvmfPkg's view, it contains a new driver similar to a core driver. Since I more care of the core packages, I prefer keep the change in OvmfPkg for now. Your solution to introducing PCD in PcAtChipSetPkg/PciHostBridgeDxe, in my point of view (as I said in above), will make the core driver more ugly. We should make the code better and better. But maybe in one step, maybe in several steps. Thanks, Ray -Original Message- From: Justen, Jordan L Sent: Tuesday, July 7, 2015 8:53 AM To: Laszlo Ersek; Ni, Ruiyu Cc: edk2-devel@lists.sourceforge.net; Kinney, Michael D; Gerd Hoffmann Subject: Re: [edk2] [PATCH v2 02/24] PcAtChipsetPkg: remove PciHostBridgeDxe On 2015-07-06 15:10:45, Laszlo Ersek wrote: On 06/28/15 01:36, Jordan Justen wrote: On 2015-06-25 21:26:20, Ni, Ruiyu wrote: Jordan, Simply using PCD to split the code is very straightforward. Another approach is to introduce a new library class with carefully defined library APIs so that different platforms can use one common driver plus different instances of libraries. After all, abstracting is never a easy work. So let's firstly make OVMF work by duplicating a PciHostBridgeDxe. Is this the preferred method of making progress then? Duplicate code first, then figure out how to make it more general? I don't see drivers duplicated all that often, so it seems a little strange. I haven't heard you say the PCD idea can't work, so can you spend a little more time considering it to see if it seems reasonable to you? If you are still concerned about the PCDs, then fine we'll just duplicate the code. And, Laszlo, is this really that urgent that you'd rather duplicate a driver under the platform rather than allowing for some discussion on a possible common solution? I'm back from my PTO. After processing my email backlog, I can't find any news related to this patchset, so please consider it dropped, for the reasons described elsewhere in this thread. This continues to be very frustrating to me. I strongly disagree with forking this driver. I have instead argued that we should make other EDK II platforms use the same driver. But, it appears that Ray will not budge. (Or *something* is preventing us from coming up with a solution in PcAtChipsetPkg.) This is doubly frustrating since he is saying that we should keep the PcAtChipsetPkg version that no one else is using because 'maybe some closed source platform is using it'. I don't expect that the PcAtChipsetPkg version will ever be updated to allow OVMF to go back to using it at the common location. Instead, it will just be orphaned under PcAtChipsetPkg. I think Ray is just taking the easy/safe route with his decision. :( But, as much as this all annoys me, I find the prospect of you having to carry downstream patches for this even worse. I'm just having trouble giving a Reviewed-by or Acked-by for patches that are doing the opposite of what I want to happen. How about? Acked-under-duress-by: Jordan Justen jordan.l.jus...@intel.com Better yet, how about I say that I'm specifically not NAK'ing the patches, but I'd rather not have my name on them. -Jordan We'll carry the patches (with slight updates) in our downstream OVMF package, for https://bugzilla.redhat.com/show_bug.cgi?id=1193080. I'll ask Gerd too to add them to his https://www.kraxel.org/repos/ builds, for the benefit of the wider public. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud
Re: [edk2] [PATCH v3 19/23] OvmfPkg: PciHostBridgeDxe: eliminate PCI_HOST_BRIDGE_INSTANCE.RootBridgeNumber
1-19 Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
On 2015-07-07 08:09:21, Laszlo Ersek wrote:
This field was supposed to store the number of root buses created; however
we don't need to keep that count persistently. After the entry point returns,
nothing reads this field.
Cc: Jordan Justen jordan.l.jus...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
Regression-tested-by: Gabriel Somlo so...@cmu.edu
---
OvmfPkg/PciHostBridgeDxe/PciHostBridge.h | 1 -
OvmfPkg/PciHostBridgeDxe/PciHostBridge.c | 4 +---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/OvmfPkg/PciHostBridgeDxe/PciHostBridge.h
b/OvmfPkg/PciHostBridgeDxe/PciHostBridge.h
index d2c28bc..617c68e 100644
--- a/OvmfPkg/PciHostBridgeDxe/PciHostBridge.h
+++ b/OvmfPkg/PciHostBridgeDxe/PciHostBridge.h
@@ -52,7 +52,6 @@ typedef enum {
typedef struct {
UINTN Signature;
EFI_HANDLEHostBridgeHandle;
- UINTN RootBridgeNumber;
LIST_ENTRYHead;
BOOLEAN ResourceSubmited;
BOOLEAN CanRestarted;
diff --git a/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
b/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
index a5dbe57..7dda75f 100644
--- a/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
+++ b/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
@@ -56,7 +56,6 @@ EFI_HANDLE mDriverImageHandle;
PCI_HOST_BRIDGE_INSTANCE mPciHostBridgeInstanceTemplate = {
PCI_HOST_BRIDGE_SIGNATURE, // Signature
NULL, // HostBridgeHandle
- 0, // RootBridgeNumber
{NULL, NULL}, // Head
FALSE, // ResourceSubiteed
TRUE, // CanRestarted
@@ -213,7 +212,6 @@ InitializePciHostBridge (
return EFI_OUT_OF_RESOURCES;
}
- HostBridge-RootBridgeNumber = 1;
InitializeListHead (HostBridge-Head);
Status = gBS-InstallMultipleProtocolInterfaces (
@@ -227,7 +225,7 @@ InitializePciHostBridge (
}
for (RootBridgeNumber = 0;
- RootBridgeNumber HostBridge-RootBridgeNumber;
+ RootBridgeNumber 1;
++RootBridgeNumber) {
Status = InitRootBridge (
(UINT8)RootBridgeNumber,
--
1.8.3.1
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v3 21/23] OvmfPkg: PciHostBridgeDxe: shorten search for extra root buses
On 2015-07-07 08:09:23, Laszlo Ersek wrote:
QEMU provides an fw_cfg file called etc/extra-pci-roots, containing a
How long were the extra roots in qemu without the fw_cfg entry?
That's a leading question for, what if we only were to only scan for
the roots if the fw_cfg entry is present?
Does seabios scan up to 255 if the fw_cfg entry is not found?
-Jordan
little-endian UINT64 value that exposes the number of extra root buses. We
can use this value to terminate the scan as soon as we find the last extra
root bus.
Cc: Jordan Justen jordan.l.jus...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
Regression-tested-by: Gabriel Somlo so...@cmu.edu
---
Notes:
v2:
- %Lu is available now in format strings, for printing UINT64 values in
decimal
OvmfPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf | 2 ++
OvmfPkg/PciHostBridgeDxe/PciHostBridge.c | 22 +++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf
b/OvmfPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf
index 40f4c3c..ca760b5 100644
--- a/OvmfPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf
+++ b/OvmfPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf
@@ -26,6 +26,7 @@ [Defines]
[Packages]
MdePkg/MdePkg.dec
+ OvmfPkg/OvmfPkg.dec
[LibraryClasses]
UefiDriverEntryPoint
@@ -39,6 +40,7 @@ [LibraryClasses]
DevicePathLib
IoLib
PciLib
+ QemuFwCfgLib
[Sources]
PciHostBridge.c
diff --git a/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
b/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
index 3486644..efef2ed 100644
--- a/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
+++ b/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
@@ -15,6 +15,8 @@
**/
+#include Library/QemuFwCfgLib.h
+
#include PciHostBridge.h
STATIC
@@ -207,6 +209,9 @@ InitializePciHostBridge (
)
{
EFI_STATUS Status;
+ FIRMWARE_CONFIG_ITEMFwCfgItem;
+ UINTN FwCfgSize;
+ UINT64 ExtraRootBridgesLeft;
UINTN LastRootBridgeNumber;
UINTN RootBridgeNumber;
PCI_HOST_BRIDGE_INSTANCE*HostBridge;
@@ -237,6 +242,20 @@ InitializePciHostBridge (
}
//
+ // QEMU provides the number of extra root buses, shortening the exhaustive
+ // search below. If there is no hint, the feature is missing.
+ //
+ Status = QemuFwCfgFindFile (etc/extra-pci-roots, FwCfgItem, FwCfgSize);
+ if (EFI_ERROR (Status) || FwCfgSize != sizeof ExtraRootBridgesLeft) {
+ExtraRootBridgesLeft = 0;
+ } else {
+QemuFwCfgSelectItem (FwCfgItem);
+QemuFwCfgReadBytes (FwCfgSize, ExtraRootBridgesLeft);
+DEBUG ((EFI_D_INFO, %a: %Lu extra root buses reported by QEMU\n,
+ __FUNCTION__, ExtraRootBridgesLeft));
+ }
+
+ //
// The main root bus is always there.
//
LastRootBridgeNumber = 0;
@@ -247,7 +266,7 @@ InitializePciHostBridge (
// alive.
//
for (RootBridgeNumber = 1;
- RootBridgeNumber 256;
+ RootBridgeNumber 256 ExtraRootBridgesLeft 0;
++RootBridgeNumber) {
UINTN Device;
@@ -271,6 +290,7 @@ InitializePciHostBridge (
}
InsertTailList (HostBridge-Head, RootBus-Link);
LastRootBridgeNumber = RootBridgeNumber;
+ --ExtraRootBridgesLeft;
}
}
--
1.8.3.1
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] IntelFrameworkPkg FrameworkUefiLib: Resolve issue brought by r17740
I think maybe the subject could be improved. I prefer to describe the
problem instead.
IntelFrameworkPkg FrameworkUefiLib: Fix ASSERT in CatVSPrint
Then, I think you can mention the r17740 regression in the main body
of the commit message.
I also have a suggestion below.
On 2015-07-07 17:46:35, Hao Wu wrote:
BufferToReturn = AllocateCopyPool(SizeRequired, String);
The above using of AllocateCopyPool() will cause ASSERT if 'String' is
NULL. Therefore, proper check for 'String' is needed.
The above using of AllocateCopyPool() will read contents out of the scope
of 'String'. Potential risk for 'String' allocated at the boundary of
memory region.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu hao.a...@intel.com
Reviewed-by: Qiu Shumin shumin@intel.com
---
IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c
b/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c
index 9a9503e..c02e653 100644
--- a/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c
+++ b/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c
@@ -754,12 +754,16 @@ CatVSPrint (
SizeRequired = sizeof(CHAR16) + (CharactersRequired * sizeof(CHAR16));
}
- BufferToReturn = AllocateCopyPool(SizeRequired, String);
+ BufferToReturn = AllocateZeroPool(SizeRequired);
What about something like this instead?
if (String != NULL) {
BufferToReturn = AllocateCopyPool(SizeRequired, String);
} else {
BufferToReturn = AllocatePool(SizeRequired);
BufferToReturn[0] = L'\0';
}
This prevents zero'ing the buffer and then copying over it, and if
String is NULL, it only null terminates the buffer rather than
zero'ing it entirely.
-Jordan
if (BufferToReturn == NULL) {
return NULL;
}
+ if (String != NULL) {
+StrCpyS(BufferToReturn, SizeRequired, String);
+ }
+
UnicodeVSPrint(BufferToReturn + StrLen(BufferToReturn),
(CharactersRequired+1) * sizeof(CHAR16), FormatString, Marker);
ASSERT(StrSize(BufferToReturn)==SizeRequired);
--
1.9.5.msysgit.0
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] OvmfPkg: Fix the build.sh shebang line to avoid depending on location of bash
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com On 2015-07-07 18:02:16, Bruce Cran wrote: The bash binary can be in various locations depending on the system: on Linux it's in /bin while on BSD it's normally in /usr/local/bin. However, the env binary is almost always in /usr/bin and so can be used to find and start the shell. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bruce Cran br...@cran.org.uk --- OvmfPkg/build.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh index b549ab5..b132d63 100755 --- a/OvmfPkg/build.sh +++ b/OvmfPkg/build.sh @@ -1,4 +1,4 @@ -#!/bin/bash +#!/usr/bin/env bash # # Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.BR # Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved.BR -- 2.4.5 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v2 02/24] PcAtChipsetPkg: remove PciHostBridgeDxe
On 2015-07-07 18:51:24, Ni, Ruiyu wrote: Jordan, Sure. I will submit patch to delete it if no one is using it. In fact, one of my colleagues disagreed to remove this driver since he is using it in his project.:) Okay. Then we should keep it. I'm just dissappointed that we can't also use it with other EDK II platforms. It seems very close to being usable by 3 of the platforms in the EDK II tree. But, now we are going from using it with 1 of those 3 platforms, to now 0 of those 3 platforms. Thanks, -Jordan -Original Message- From: Justen, Jordan L Sent: Wednesday, July 8, 2015 7:51 AM To: Ni, Ruiyu; Laszlo Ersek Cc: edk2-devel@lists.sourceforge.net; Kinney, Michael D; Gerd Hoffmann Subject: RE: [edk2] [PATCH v2 02/24] PcAtChipsetPkg: remove PciHostBridgeDxe On 2015-07-06 19:25:37, Ni, Ruiyu wrote: Jordan, Laszlo, I personally strongly disagree using PCD to split code to make the code common. Well, at least a definitive statement. :) Previously you did not seem to have much of an opinion on it: Simply using PCD to split the code is very straightforward. Another approach is to introduce a new library class with carefully defined library APIs so that different platforms can use one common driver plus different instances of libraries. I'm really doubtful that a library class will ever be developed to allow OVMF to return to using the PcAtChipsetPkg version of the driver. I guess we will leave PcAtChipsetPkg/PciHostBridgeDxe to you and all those closed source platforms. I still hope you'll look into it more and consider deleting PcAtChipsetPkg/PciHostBridgeDxe if no one is actually using it. Thanks, -Jordan PCD is a very fashion word in EDKII world but most of the time it downgrades to C macro. Do you think one piece of common code heavily using macro is better than two pieces of code? I doubt that! So unless someone (either you or Laszlo) can propose a better solution to generalize the code, I would prefer to duplicate the code in OvmfPkg first. From the view of core packages, there is no change. From OvmfPkg's view, it contains a new driver similar to a core driver. Since I more care of the core packages, I prefer keep the change in OvmfPkg for now. Your solution to introducing PCD in PcAtChipSetPkg/PciHostBridgeDxe, in my point of view (as I said in above), will make the core driver more ugly. We should make the code better and better. But maybe in one step, maybe in several steps. Thanks, Ray -Original Message- From: Justen, Jordan L Sent: Tuesday, July 7, 2015 8:53 AM To: Laszlo Ersek; Ni, Ruiyu Cc: edk2-devel@lists.sourceforge.net; Kinney, Michael D; Gerd Hoffmann Subject: Re: [edk2] [PATCH v2 02/24] PcAtChipsetPkg: remove PciHostBridgeDxe On 2015-07-06 15:10:45, Laszlo Ersek wrote: On 06/28/15 01:36, Jordan Justen wrote: On 2015-06-25 21:26:20, Ni, Ruiyu wrote: Jordan, Simply using PCD to split the code is very straightforward. Another approach is to introduce a new library class with carefully defined library APIs so that different platforms can use one common driver plus different instances of libraries. After all, abstracting is never a easy work. So let's firstly make OVMF work by duplicating a PciHostBridgeDxe. Is this the preferred method of making progress then? Duplicate code first, then figure out how to make it more general? I don't see drivers duplicated all that often, so it seems a little strange. I haven't heard you say the PCD idea can't work, so can you spend a little more time considering it to see if it seems reasonable to you? If you are still concerned about the PCDs, then fine we'll just duplicate the code. And, Laszlo, is this really that urgent that you'd rather duplicate a driver under the platform rather than allowing for some discussion on a possible common solution? I'm back from my PTO. After processing my email backlog, I can't find any news related to this patchset, so please consider it dropped, for the reasons described elsewhere in this thread. This continues to be very frustrating to me. I strongly disagree with forking this driver. I have instead argued that we should make other EDK II platforms use the same driver. But, it appears that Ray will not budge. (Or *something* is preventing us from coming up with a solution in PcAtChipsetPkg.) This is doubly frustrating since he is saying that we should keep the PcAtChipsetPkg version that no one else is using because 'maybe some closed source platform is using it'. I don't expect that the PcAtChipsetPkg version will ever be updated to allow OVMF to go back to using it at the common location. Instead
Re: [edk2] Replacement EDK2 email list coming soon
On 2015-07-04 15:56:05, B Cran wrote: On May 4, 2015, at 2:21 PM, Peterson, Joe joe.peter...@intel.com wrote: Due to community feedback, a new mailing list is being set up to replace this one. The new list will be hosted on Lists.01.org and should be more stable and consistent than this one. The host has an opt-in policy and will not allow the current subscription list to be imported so you will need to subscribe yourself. The timing of the final conversion to the new list is still to be determined, but in the meantime you can sign up for the new list here: https://lists.01.org/mailman/listinfo/edk2 Please keep all relevant communications on this channel and do not use the new one for patches or questions yet. Feel free to post questions/comment/concerns to this current list. Stay tuned for more updates... A list of the content changes / improvement being worked can be found here:http://www.tianocore.org/news/2015/05/01/UnderConst.html Since it has been about 2 months since this was sent, I was wondering if there's any update regarding plans, timing etc.? Joe is out of the office currently, so I'm going to take over on this task. I plan to transition the list over the next week or two. (I'll send out a separate email with the details.) Note that compared to the original announcement the list has been renamed from edk2 to edk2-devel. https://lists.01.org/mailman/listinfo/edk2-devel -Jordan -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v2 02/24] PcAtChipsetPkg: remove PciHostBridgeDxe
On 2015-07-06 15:10:45, Laszlo Ersek wrote: On 06/28/15 01:36, Jordan Justen wrote: On 2015-06-25 21:26:20, Ni, Ruiyu wrote: Jordan, Simply using PCD to split the code is very straightforward. Another approach is to introduce a new library class with carefully defined library APIs so that different platforms can use one common driver plus different instances of libraries. After all, abstracting is never a easy work. So let's firstly make OVMF work by duplicating a PciHostBridgeDxe. Is this the preferred method of making progress then? Duplicate code first, then figure out how to make it more general? I don't see drivers duplicated all that often, so it seems a little strange. I haven't heard you say the PCD idea can't work, so can you spend a little more time considering it to see if it seems reasonable to you? If you are still concerned about the PCDs, then fine we'll just duplicate the code. And, Laszlo, is this really that urgent that you'd rather duplicate a driver under the platform rather than allowing for some discussion on a possible common solution? I'm back from my PTO. After processing my email backlog, I can't find any news related to this patchset, so please consider it dropped, for the reasons described elsewhere in this thread. This continues to be very frustrating to me. I strongly disagree with forking this driver. I have instead argued that we should make other EDK II platforms use the same driver. But, it appears that Ray will not budge. (Or *something* is preventing us from coming up with a solution in PcAtChipsetPkg.) This is doubly frustrating since he is saying that we should keep the PcAtChipsetPkg version that no one else is using because 'maybe some closed source platform is using it'. I don't expect that the PcAtChipsetPkg version will ever be updated to allow OVMF to go back to using it at the common location. Instead, it will just be orphaned under PcAtChipsetPkg. I think Ray is just taking the easy/safe route with his decision. :( But, as much as this all annoys me, I find the prospect of you having to carry downstream patches for this even worse. I'm just having trouble giving a Reviewed-by or Acked-by for patches that are doing the opposite of what I want to happen. How about? Acked-under-duress-by: Jordan Justen jordan.l.jus...@intel.com Better yet, how about I say that I'm specifically not NAK'ing the patches, but I'd rather not have my name on them. -Jordan We'll carry the patches (with slight updates) in our downstream OVMF package, for https://bugzilla.redhat.com/show_bug.cgi?id=1193080. I'll ask Gerd too to add them to his https://www.kraxel.org/repos/ builds, for the benefit of the wider public. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] URGENT SVN screwup [Re: [PATCH 0/5] MdeModulePkg: clean up Properties Table implementation and adapt it to AArch64]
On 2015-07-01 23:51:19, Ard Biesheuvel wrote: On 2 July 2015 at 08:38, Ard Biesheuvel ard.biesheu...@linaro.org wrote: Liming, Jordan, Jiewen. I appeared to have screwed up something performing the push Could you please rewind SVN to r17801 ? Apologies for sounding a bit panicky, but it would be useful if those commits could be removed before the sync to github (iow, in the next 10 minutes) Whoops. Didn't see this in time. I'll add a revert commit, and then sync the tree... -Jordan -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools: fix a syntax error in 4 KB aligned GNU ld linker script
On 2015-07-01 22:35:12, Gao, Liming wrote: Ard: Good to know --script option can be appended and work fine. So, --script will be specified twice to ld. This seems like a very fragile implementation of a new UEFI feature. Is this the long term plan? Do Visual Studio based builds do something similar? -Jordan -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Thursday, July 02, 2015 1:05 PM To: Justen, Jordan L Cc: Gao, Liming; Liu, Yingke D; edk2-devel@lists.sourceforge.net Subject: Re: [PATCH] BaseTools: fix a syntax error in 4 KB aligned GNU ld linker script On 2 July 2015 at 02:54, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-07-01 17:41:11, Gao, Liming wrote: Jordan: Agree. We will follow this rule, apply the patch and push it without any modification. My point is that if there is a mistake, we should not bother to update the log message to fix that mistake. Hopefully we can just be more careful with the patch message if we stop thinking that we can go back and fix it later. :) gcc-4k is added for new UEFI2.5 Properties Table. When enable this feature, gcc-4k script will be required for RUNTIME driver. It can be configured in [BuildOptions] of DSC file for RUNTIME driver only. We could update Ovmf to enable this feature, which can be turned on/off by build flag. Is it OK to you? Is there an example of how to enable it for a platform? Or, the feature is still is not fully complete? Hello Jordan, As I reported here: http://article.gmane.org/gmane.comp.bios.tianocore.devel/16433 I gave this a quick spin by adding this --8 diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index e5fc90d2e610..7f06b51f65cf 100644 --- a/OvmfPkg/OvmfPkgX64.dsc +++ b/OvmfPkg/OvmfPkgX64.dsc @@ -48,6 +48,9 @@ [BuildOptions] INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable !endif +[BuildOptions.X64.EDKII.DXE_RUNTIME_DRIVER] + GCC:*_*_*_DLINK_FLAGS = --script=$(EDK_TOOLS_PATH)/Scripts/gcc-4K-align-ld-script + # # SKU Identification section - list of all SKU IDs supported by this Platform. --8 to the OvmfPkg build, and it appears to work fine. There are a couple of things to be aware of, though. - It depends on Laszlo's end-of-dxe series http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16304 - Adding subsequent --script arguments to GNU ld accumulates linker scripts instead of replacing them. This works correctly in this case since the linker scripts are identical except for the section alignments, but it is something to keep in mind. - It crashes the Linux kernel at boot. The crash seems to be inside SetVirtualAddressMap (), which suggests that X64 Linux suffers from the same problem as AARCH64, i.e., that the virtual mapping does not preserve the offset between adjacent code and data regions. This is not required by the spec, though, so this feature essentially breaks backward compatibility. The latter is a huge concern imo, since the fact that it breaks older OSes will impede the adoption of an otherwise very useful security feature. Regards, Ard. -Original Message- From: Justen, Jordan L Sent: Thursday, July 2, 2015 6:42 AM To: Liu, Yingke D; Ard Biesheuvel Cc: edk2-devel@lists.sourceforge.net; Gao, Liming Subject: RE: [PATCH] BaseTools: fix a syntax error in 4 KB aligned GNU ld linker script On 2015-07-01 01:34:56, Liu, Yingke D wrote: Hi Ard, Thanks for the comments, I have updated the log message. For future reference, I think you should not bother to update the log message. It is a bad practice, and the git archive will not see the updated log message anyhow. It should also be noted that it will not be possible to update the commit message when git is the main upstream repo. I think it is best just to acknowledge the mistake, and remember it for next time. I have a question. Where is the 4K script used? git grep gcc-4K shows no references to it. -Jordan -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Wednesday, July 01, 2015 16:12 To: Liu, Yingke D Cc: edk2-devel@lists.sourceforge.net; Justen, Jordan L; Gao, Liming Subject: Re: [PATCH] BaseTools: fix a syntax error in 4 KB aligned GNU ld linker script On 30 June 2015 at 13:02, Gao, Liming liming@intel.com wrote: Reviewed-by: Liming Gao liming@intel.com Hello Dennis, Thanks for merging this. Next time, could you please keep the subject line as well? Subject: [PATCH] BaseTools: fix a syntax error in 4 KB aligned GNU ld linker script You have used this instead: There needs to be a space between the output section name and the colon, i.e
Re: [edk2] URGENT SVN screwup [Re: [PATCH 0/5] MdeModulePkg: clean up Properties Table implementation and adapt it to AArch64]
On 2015-07-02 00:10:40, Jordan Justen wrote: On 2015-07-01 23:51:19, Ard Biesheuvel wrote: On 2 July 2015 at 08:38, Ard Biesheuvel ard.biesheu...@linaro.org wrote: Liming, Jordan, Jiewen. I appeared to have screwed up something performing the push Could you please rewind SVN to r17801 ? Apologies for sounding a bit panicky, but it would be useful if those commits could be removed before the sync to github (iow, in the next 10 minutes) Whoops. Didn't see this in time. I'll add a revert commit, and then sync the tree... Done. Let me know if it doesn't look right. -Jordan -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH V4 08/21] Nt32Pkg: Link AuthVariableLib for following merged variable driver deploy
On 2015-06-30 02:01:24, Star Zeng wrote: AuthVariableLib and TpmMeasurementLib library classes are now linked with MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf to optionally support secure variables. For Nt32Pkg, link AuthVariableLib and DxeTpmMeasurementLib in SecurityPkg when SECURE_BOOT_ENABLE = TRUE, and link AuthVariableLibNull and TpmMeasurementLibNull in MdeModulePkg when SECURE_BOOT_ENABLE = FALSE. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng star.z...@intel.com Reviewed-by: Ruiyu Ni ruiyu...@intel.com Reviewed-by: Jordan Justen jordan.l.jus...@intel.com I didn't actually give my r-b for patch 8 or 9. (I wanted to see how the commit message was re-worded first.) But, if you fix the subject line of these patches to be more like patch 10, then you can keep my r-b on them. Oh ... I see you already committed the patches. -Jordan --- Nt32Pkg/Nt32Pkg.dsc | 4 1 file changed, 4 insertions(+) diff --git a/Nt32Pkg/Nt32Pkg.dsc b/Nt32Pkg/Nt32Pkg.dsc index b0d3fbf..2344d9a 100644 --- a/Nt32Pkg/Nt32Pkg.dsc +++ b/Nt32Pkg/Nt32Pkg.dsc @@ -136,6 +136,10 @@ [LibraryClasses] IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf + AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf +!else + TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf + AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif [LibraryClasses.common.USER_DEFINED] -- 1.9.5.msysgit.0 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH V4 08/21] Nt32Pkg: Link AuthVariableLib for following merged variable driver deploy
On 2015-07-01 00:26:26, Zeng, Star wrote: Ok, miss understanding. Nt32Pkg: Link AuthVariableLib for following merged variable driver deploy. OvmfPkg: Link AuthVariableLib for following merged variable driver deploy. For these two, do you think the commit message could be improved similar to my EmulatorPkg suggestion? In fact, I enhanced the commit message content to be similar with EmulatorPkg, but not the subject line. I see. I think of the subject line as part of the commit message, so I meant the feedback to include that. AuthVariableLib and TpmMeasurementLib library classes are now linked with MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf to optionally support secure variables. For Nt32Pkg, link AuthVariableLib and DxeTpmMeasurementLib in SecurityPkg when SECURE_BOOT_ENABLE = TRUE, and link AuthVariableLibNull and TpmMeasurementLibNull in MdeModulePkg when SECURE_BOOT_ENABLE = FALSE. EmulatorPkg only need one patch to link NULL instances, but other Nt32Pkg and OvmfPkg need to have the second patch to use merged variable driver, so I keep the subject line, especially I want to emphasize for following merged variable driver. And I also added notes in cover letter of V3 patchset According to the feedback from Laszlo Ersek ler...@redhat.com, Ard Biesheuvel ard.biesheu...@linaro.org and Jordan Justen jordan.l.jus...@intel.com, update the patches for ArmVirtPkg and update some commit messages for some platform packages.. Anyway, do you need to update the committed commit log to remove your r-b(in SVN commit log, I know it could not be into github). No. It is okay. Thanks for the patches! I think it is good to merge those two variable drivers. In fact, a while ago I wanted to replace the Variable/EmuRuntimeDxe by using an emu-fvb like OvmfPkg/EmuVariableFvbRuntimeDxe. This way we would only have 1 variable driver. (I think the emu-fvb solution could work for DUET's variables as well.) Unfortunately, my plan didn't make any progress beyond OVMF... -Jordan -Original Message- From: Justen, Jordan L Sent: Wednesday, July 1, 2015 3:10 PM To: edk2-devel@lists.sourceforge.net; Zeng, Star; edk2-devel@lists.sourceforge.net Subject: Re: [edk2] [PATCH V4 08/21] Nt32Pkg: Link AuthVariableLib for following merged variable driver deploy On 2015-06-30 02:01:24, Star Zeng wrote: AuthVariableLib and TpmMeasurementLib library classes are now linked with MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf to optionally support secure variables. For Nt32Pkg, link AuthVariableLib and DxeTpmMeasurementLib in SecurityPkg when SECURE_BOOT_ENABLE = TRUE, and link AuthVariableLibNull and TpmMeasurementLibNull in MdeModulePkg when SECURE_BOOT_ENABLE = FALSE. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng star.z...@intel.com Reviewed-by: Ruiyu Ni ruiyu...@intel.com Reviewed-by: Jordan Justen jordan.l.jus...@intel.com I didn't actually give my r-b for patch 8 or 9. (I wanted to see how the commit message was re-worded first.) But, if you fix the subject line of these patches to be more like patch 10, then you can keep my r-b on them. Oh ... I see you already committed the patches. -Jordan --- Nt32Pkg/Nt32Pkg.dsc | 4 1 file changed, 4 insertions(+) diff --git a/Nt32Pkg/Nt32Pkg.dsc b/Nt32Pkg/Nt32Pkg.dsc index b0d3fbf..2344d9a 100644 --- a/Nt32Pkg/Nt32Pkg.dsc +++ b/Nt32Pkg/Nt32Pkg.dsc @@ -136,6 +136,10 @@ [LibraryClasses] IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasu rementLib.inf + +AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.i +nf +!else + +TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasu +rementLibNull.inf + +AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariable +LibNull.inf !endif [LibraryClasses.common.USER_DEFINED] -- 1.9.5.msysgit.0 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel According to the feedback from Laszlo Ersek ler...@redhat.com, Ard Biesheuvel ard.biesheu...@linaro.org and Jordan Justen jordan.l.jus...@intel.com, update the patches for ArmVirtPkg and update some commit messages for some platform packages. For your easy review
Re: [edk2] [PATCH 13/13] MdeModulePkg/Universal/Variable: Use safe string functions to refine code.
In the future, can you use git bash with 'git send-email *.patch' so all the emails in your patch series will be sent as a single email thread? The TortoiseGit GUI can't do this correctly. I think that you'll also find that 'git send-email *.patch' is faster. Thanks, -Jordan On 2015-06-25 00:47:09, Qiu Shumin wrote: Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qiu Shumin shumin@intel.com --- MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c | 6 +++--- MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c | 2 +- MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 6 +++--- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c b/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c index e076840..977332e 100644 --- a/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c +++ b/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c @@ -3,7 +3,7 @@ Emulation Variable services operate on the runtime volatile memory. The nonvolatile variable space doesn't exist. -Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.BR +Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.BR This program and the accompanying materials are licensed and made available under the terms and conditions of the BSD License which accompanies this distribution. The full text of the license may be found at @@ -322,7 +322,7 @@ UpdateVariableInfo ( CopyGuid (gVariableInfo-VendorGuid, VendorGuid); gVariableInfo-Name = AllocateZeroPool (StrSize (VariableName)); ASSERT (gVariableInfo-Name != NULL); - StrnCpy (gVariableInfo-Name, VariableName, StrLen (VariableName)); + StrCpyS (gVariableInfo-Name, StrSize(VariableName)/sizeof(CHAR16), VariableName); gVariableInfo-Volatile = Volatile; gBS-InstallConfigurationTable (gEfiVariableGuid, gVariableInfo); @@ -360,7 +360,7 @@ UpdateVariableInfo ( CopyGuid (Entry-Next-VendorGuid, VendorGuid); Entry-Next-Name = AllocateZeroPool (StrSize (VariableName)); ASSERT (Entry-Next-Name != NULL); -StrnCpy (Entry-Next-Name, VariableName, StrLen (VariableName)); +StrCpyS (Entry-Next-Name, StrSize(VariableName)/sizeof(CHAR16), VariableName); Entry-Next-Volatile = Volatile; } diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c b/MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c index b2f5572..0586e41 100644 --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c @@ -1048,7 +1048,7 @@ VarCheckVariablePropertySet ( goto Done; } VariableName = (CHAR16 *) ((UINTN) Entry + sizeof (*Entry)); -StrnCpy (VariableName, Name, StrLen (Name)); +StrCpyS (VariableName, StrSize(Name)/sizeof(CHAR16), Name); CopyGuid (Entry-Guid, Guid); CopyMem (Entry-VariableProperty, VariableProperty, sizeof (*VariableProperty)); InsertTailList (mVarCheckVariableList, Entry-Link); diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c index a4104cc..4ef1240 100644 --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c @@ -111,7 +111,7 @@ UpdateVariableInfo ( CopyGuid (gVariableInfo-VendorGuid, VendorGuid); gVariableInfo-Name = AllocateZeroPool (StrSize (VariableName)); ASSERT (gVariableInfo-Name != NULL); - StrnCpy (gVariableInfo-Name, VariableName, StrLen (VariableName)); + StrCpyS (gVariableInfo-Name, StrSize(VariableName)/sizeof(CHAR16), VariableName); gVariableInfo-Volatile = Volatile; } @@ -147,7 +147,7 @@ UpdateVariableInfo ( CopyGuid (Entry-Next-VendorGuid, VendorGuid); Entry-Next-Name = AllocateZeroPool (StrSize (VariableName)); ASSERT (Entry-Next-Name != NULL); -StrnCpy (Entry-Next-Name, VariableName, StrLen (VariableName)); +StrCpyS (Entry-Next-Name, StrSize(VariableName)/sizeof(CHAR16), VariableName); Entry-Next-Volatile = Volatile; } @@ -2450,7 +2450,7 @@ VariableLockRequestToLock ( } Name = (CHAR16 *) ((UINTN) Entry + sizeof (*Entry)); - StrnCpy (Name, VariableName, StrLen (VariableName)); + StrCpyS (Name, StrSize (VariableName)/sizeof(CHAR16), VariableName); CopyGuid (Entry-Guid, VendorGuid); InsertTailList (mLockedVariableList, Entry-Link); -- 1.9.5.msysgit.1 -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25
Re: [edk2] [PATCH] BaseTools: fix a syntax error in 4 KB aligned GNU ld linker script
On 2015-07-01 01:34:56, Liu, Yingke D wrote:
Hi Ard,
Thanks for the comments, I have updated the log message.
For future reference, I think you should not bother to update the log
message. It is a bad practice, and the git archive will not see the
updated log message anyhow. It should also be noted that it will not
be possible to update the commit message when git is the main upstream
repo.
I think it is best just to acknowledge the mistake, and remember it
for next time.
I have a question. Where is the 4K script used? git grep gcc-4K shows
no references to it.
-Jordan
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Wednesday, July 01, 2015 16:12
To: Liu, Yingke D
Cc: edk2-devel@lists.sourceforge.net; Justen, Jordan L; Gao, Liming
Subject: Re: [PATCH] BaseTools: fix a syntax error in 4 KB aligned GNU ld
linker script
On 30 June 2015 at 13:02, Gao, Liming liming@intel.com wrote:
Reviewed-by: Liming Gao liming@intel.com
Hello Dennis,
Thanks for merging this.
Next time, could you please keep the subject line as well?
Subject: [PATCH] BaseTools: fix a syntax error in 4 KB aligned GNU ld
linker script
You have used this instead:
There needs to be a space between the output section name and the colon,
i.e.,
as the subject line which looks a little silly imo
Thanks,
Ard.
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Tuesday, June 30, 2015 7:00 PM
To: Liu, Yingke D; Gao, Liming; edk2-devel@lists.sourceforge.net
Cc: Ard Biesheuvel
Subject: [PATCH] BaseTools: fix a syntax error in 4 KB aligned GNU ld
linker script
There needs to be a space between the output section name and the colon,
i.e.,
.text : ALIGN(0x1000)
^
Fix this for all output sections
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
BaseTools/Scripts/gcc-4K-align-ld-script | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/BaseTools/Scripts/gcc-4K-align-ld-script
b/BaseTools/Scripts/gcc-4K-align-ld-script
index 1f23079023a6..16cf623a3362 100644
--- a/BaseTools/Scripts/gcc-4K-align-ld-script
+++ b/BaseTools/Scripts/gcc-4K-align-ld-script
@@ -3,12 +3,12 @@ SECTIONS
{
/* . = 0 + SIZEOF_HEADERS; */
. = 0x280;
- .text: ALIGN(0x1000)
+ .text : ALIGN(0x1000)
{
*(.text .stub .text.* .gnu.linkonce.t.*)
. = ALIGN(0x20);
}
- .data: ALIGN(0x1000)
+ .data : ALIGN(0x1000)
{
*(
.rodata .rodata.* .gnu.linkonce.r.* @@ -18,16 +18,16 @@ SECTIONS
)
. = ALIGN(0x20);
}
- .eh_frame: ALIGN(0x1000)
+ .eh_frame : ALIGN(0x1000)
{
KEEP (*(.eh_frame))
}
- .got: ALIGN(0x1000)
+ .got : ALIGN(0x1000)
{
*(.got .got.*)
. = ALIGN(0x20);
}
- .rela: ALIGN(0x1000)
+ .rela : ALIGN(0x1000)
{
*(.rela .rela.*)
}
--
1.9.1
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools: fix a syntax error in 4 KB aligned GNU ld linker script
On 2015-07-01 17:41:11, Gao, Liming wrote:
Jordan:
Agree. We will follow this rule, apply the patch and push it
without any modification.
My point is that if there is a mistake, we should not bother to update
the log message to fix that mistake. Hopefully we can just be more
careful with the patch message if we stop thinking that we can go back
and fix it later. :)
gcc-4k is added for new UEFI2.5 Properties Table. When enable this
feature, gcc-4k script will be required for RUNTIME driver. It can
be configured in [BuildOptions] of DSC file for RUNTIME driver
only. We could update Ovmf to enable this feature, which can be
turned on/off by build flag. Is it OK to you?
Is there an example of how to enable it for a platform? Or, the
feature is still is not fully complete?
-Jordan
-Original Message-
From: Justen, Jordan L
Sent: Thursday, July 2, 2015 6:42 AM
To: Liu, Yingke D; Ard Biesheuvel
Cc: edk2-devel@lists.sourceforge.net; Gao, Liming
Subject: RE: [PATCH] BaseTools: fix a syntax error in 4 KB aligned GNU ld
linker script
On 2015-07-01 01:34:56, Liu, Yingke D wrote:
Hi Ard,
Thanks for the comments, I have updated the log message.
For future reference, I think you should not bother to update the
log message. It is a bad practice, and the git archive will not see
the updated log message anyhow. It should also be noted that it will
not be possible to update the commit message when git is the main
upstream repo.
I think it is best just to acknowledge the mistake, and remember it
for next time.
I have a question. Where is the 4K script used? git grep gcc-4K
shows no references to it.
-Jordan
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Wednesday, July 01, 2015 16:12
To: Liu, Yingke D
Cc: edk2-devel@lists.sourceforge.net; Justen, Jordan L; Gao, Liming
Subject: Re: [PATCH] BaseTools: fix a syntax error in 4 KB aligned GNU
ld linker script
On 30 June 2015 at 13:02, Gao, Liming liming@intel.com wrote:
Reviewed-by: Liming Gao liming@intel.com
Hello Dennis,
Thanks for merging this.
Next time, could you please keep the subject line as well?
Subject: [PATCH] BaseTools: fix a syntax error in 4 KB aligned GNU
ld linker script
You have used this instead:
There needs to be a space between the output section name and the
colon, i.e.,
as the subject line which looks a little silly imo
Thanks,
Ard.
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Tuesday, June 30, 2015 7:00 PM
To: Liu, Yingke D; Gao, Liming; edk2-devel@lists.sourceforge.net
Cc: Ard Biesheuvel
Subject: [PATCH] BaseTools: fix a syntax error in 4 KB aligned GNU
ld linker script
There needs to be a space between the output section name and the
colon, i.e.,
.text : ALIGN(0x1000)
^
Fix this for all output sections
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
BaseTools/Scripts/gcc-4K-align-ld-script | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/BaseTools/Scripts/gcc-4K-align-ld-script
b/BaseTools/Scripts/gcc-4K-align-ld-script
index 1f23079023a6..16cf623a3362 100644
--- a/BaseTools/Scripts/gcc-4K-align-ld-script
+++ b/BaseTools/Scripts/gcc-4K-align-ld-script
@@ -3,12 +3,12 @@ SECTIONS
{
/* . = 0 + SIZEOF_HEADERS; */
. = 0x280;
- .text: ALIGN(0x1000)
+ .text : ALIGN(0x1000)
{
*(.text .stub .text.* .gnu.linkonce.t.*)
. = ALIGN(0x20);
}
- .data: ALIGN(0x1000)
+ .data : ALIGN(0x1000)
{
*(
.rodata .rodata.* .gnu.linkonce.r.* @@ -18,16 +18,16 @@ SECTIONS
)
. = ALIGN(0x20);
}
- .eh_frame: ALIGN(0x1000)
+ .eh_frame : ALIGN(0x1000)
{
KEEP (*(.eh_frame))
}
- .got: ALIGN(0x1000)
+ .got : ALIGN(0x1000)
{
*(.got .got.*)
. = ALIGN(0x20);
}
- .rela: ALIGN(0x1000)
+ .rela : ALIGN(0x1000)
{
*(.rela .rela.*)
}
--
1.9.1
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH V2 10/24] EmulatorPkg: Link AuthVariableLib for following merged variable driver deploy.
On 2015-06-28 22:25:49, Zeng, Star wrote:
I mean they are linked only by VaribleRuntimeDxe.inf.
I guess you like this updated V3 patch for EmulatorPkg, right?
How about this change to the commit message?
===
EmulatorPkg: Add TpmMeasurementLib and AuthVariableLib library mapping
These library classes are now linked with
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf to
optionally support secure variables.
For EmulatorPkg, secure boot is not currently enabled, so we map these
libraries to the NULL versions that don't support secure variables.
===
With a commit message similar to that, you can add my
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
to the patch you attached.
Thanks,
-Jordan
-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Monday, June 29, 2015 1:07 PM
To: Justen, Jordan L; edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH V2 10/24] EmulatorPkg: Link AuthVariableLib for
following merged variable driver deploy.
As they are linked by VaribleRuntimeDxe.inf.
You prefer to add them to library class section, right? If yes, I am ok to
move them to library class section.
In fact, I am neutral for that to link with the *.inf or library class
section.
Thanks,
Star
-Original Message-
From: Justen, Jordan L
Sent: Monday, June 29, 2015 1:02 PM
To: Zeng, Star; edk2-devel@lists.sourceforge.net
Cc: Andrew Fish
Subject: Re: [PATCH V2 10/24] EmulatorPkg: Link AuthVariableLib for following
merged variable driver deploy.
On 2015-06-26 01:37:47, Star Zeng wrote:
Link AuthVariableLibNull and TpmMeasurementLibNull in MdeModulePkg.
Cc: Jordan Justen jordan.l.jus...@intel.com
Cc: Andrew Fish af...@apple.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
EmulatorPkg/EmulatorPkg.dsc | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index d02997c..c2f1a16 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -4,7 +4,7 @@
# The Emulation Platform can be used to debug individual modules,
prior to creating # a real platform. This also provides an example for how
an DSC is created.
#
-# Copyright (c) 2006 - 2013, Intel Corporation. All rights
reserved.BR
+# Copyright (c) 2006 - 2015, Intel Corporation. All rights
+reserved.BR
# Portions copyright (c) 2010 - 2011, Apple Inc. All rights
reserved.BR # # This program and the accompanying materials @@
-312,7 +312,11 @@
EmulatorPkg/TimerDxe/Timer.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+LibraryClasses
+
+ TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeas
+ urementLibNull.inf
+
+ AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariabl
+ eLibNull.inf
+ }
Why not add these to the library classes sections rather than overriding for
the driver?
-Jordan
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
--
1.9.5.msysgit.0
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors network
devices and physical virtual servers, alerts via email sms for fault.
Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical virtual servers, alerts via email sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH V2 00/24] Separate auth variable service from Auth Variable driver.
On 2015-06-26 01:37:37, Star Zeng wrote: Nt32Pkg: Link AuthVariableLib for following merged variable driver deploy. OvmfPkg: Link AuthVariableLib for following merged variable driver deploy. For these two, do you think the commit message could be improved similar to my EmulatorPkg suggestion? Nt32Pkg: Use the merged Variable driver. OvmfPkg: Use the merged Variable driver. The period (.) seems unnecessary at the end of the subject line. For these two, you can add Reviewed-by: Jordan Justen jordan.l.jus...@intel.com -Jordan -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH V2 10/24] EmulatorPkg: Link AuthVariableLib for following merged variable driver deploy.
On 2015-06-26 01:37:47, Star Zeng wrote:
Link AuthVariableLibNull and TpmMeasurementLibNull in MdeModulePkg.
Cc: Jordan Justen jordan.l.jus...@intel.com
Cc: Andrew Fish af...@apple.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
EmulatorPkg/EmulatorPkg.dsc | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index d02997c..c2f1a16 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -4,7 +4,7 @@
# The Emulation Platform can be used to debug individual modules, prior to
creating
# a real platform. This also provides an example for how an DSC is created.
#
-# Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.BR
+# Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.BR
# Portions copyright (c) 2010 - 2011, Apple Inc. All rights reserved.BR
#
# This program and the accompanying materials
@@ -312,7 +312,11 @@
EmulatorPkg/TimerDxe/Timer.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+LibraryClasses
+
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
+ }
Why not add these to the library classes sections rather than
overriding for the driver?
-Jordan
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
--
1.9.5.msysgit.0
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical virtual servers, alerts via email sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH 0/9] multiple packages: save S3 state at EndOfDxe
Patches 1-4 7-9: Reviewed-by: Jordan Justen jordan.l.jus...@intel.com For Patches 5 6, I would like to ask if the 'end-of-dxe' signal could be added as separate patches. (Inserted before 5/6, I assume.) Would that be possible, or would the S3 interdependencies prevent it? It seems like that is important enough of a platform change that it should stand on its own, if possible. It would also be nice if MdePkg had a PiLib so we could add a EndOfDxe functions, similar to EfiSignalEventReadyToBoot and EfiCreateEventReadyToBootEx. -Jordan On 2015-06-26 18:08:07, Laszlo Ersek wrote: In http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16146, Jiewen proposed: And in the future, I believe we could remove EFI_ACPI_S3_SAVE_PROTOCOL protocol completely. (This is Framework 0.9 defined API, not PI defined API) The better design might be: 1) AcpiS3Save does not install EFI_ACPI_S3_SAVE_PROTOCOL. 2) AcpiS3Save registers EndOfDxe callback function. 3) AcpiS3Save does S3Save() in EndOfDxe callback function. So everything could be self-contained. There is no need to rely on platform BDS. Then this module eliminates IntelFrameworkPkg dependency and can be moved to MdeModulePkg later. This series implements the idea, and on the side, it changes OVMF to kick the EndOfDxe event group (which is where the entire discussion has come from -- Ard started it because ArmVirtPkg lacked EndOfDxe). The series is organized carefully. It is bisectable, plus it has another, orthogonal dimension (see below). The structure is: - Patches #1 and #2 make IntelFrameworkModulePkg/AcpiS3SaveDxe act upon EndOfDxe *in addition to* the usual S3Save() protocol member call. - Patches #3 and #4 do the same to OvmfPkg's clone of the driver. (Before anyone asks: yes, that clone needs to remain separate.) - Patch #5 modifies Vlv2TbltDevicePkg. That package is the only one in the edk2 tree that uses IntelFrameworkModulePkg/AcpiS3SaveDxe. Because I'm implementing Jiewen's idea in IntelFrameworkModulePkg/AcpiS3SaveDxe, I must migrate the driver's clients, and Vlv2TbltDevicePkg is one client. (The only one.) So patch #5 flips Vlv2TbltDevicePkg from calling the S3Save() protocol member to kicking the EndOfDxe event group. Unfortunately, I couldn't even *compile* this package, let alone test it. Thus, I need help with this patch. Importantly, because Vlv2TbltDevicePkg has its own clone of GenericBdsLib, Ard's patch (patch #7) below does *not* affect it. Therefore the Vlv2TbltDevicePkg changes are completely isolated to patch #5. - Patch #6 switches over OvmfPkg from depending on the S3Save() protocol member call (inside IntelFrameworkModulePkg/GenericBdsLib) to kicking EndOfDxe explicitly. - Patch #7 is the one from Ard. It eliminates the S3Save() protocol member call in IntelFrameworkModulePkg/GenericBdsLib. - After patch #5, nothing in the edk2 tree depends on the EFI_ACPI_S3_SAVE_PROTOCOL interface exported by IntelFrameworkModulePkg/AcpiS3SaveDxe, so that interface is removed in patch #8. - After patches #6 and #7, nothing in the edk2 tree depends on the EFI_ACPI_S3_SAVE_PROTOCOL interface exported by OvmfPkg/AcpiS3SaveDxe. Therefore that interface is removed in patch #9. Now here comes the orthogonal dimension: the sub-series consisting of patches #3, #4, #6, #7 and #9 implements Jiewen's idea for OvmfPkg *only*. It does affect central code in one patch (in Ard's patch #7), but that central code is actually not used by anything except OvmfPkg, because Vlv2TbltDevicePkg has its own clone of GenericBdsLib. So, if patches #1, #2, #5 and #8 look problematic, then I'm completely fine dropping them. Then IntelFrameworkModulePkg/AcpiS3SaveDxe and Vlv2TbltDevicePkg won't be touched at all, and Jiewen's idea (and the kicking of EndOfDxe) will only be implemented for OvmfPkg. I regression tested OVMF with these changes: S3 continues to work fine with Fedora and Windows Server 2012 R2, and they also boot okay (and reject S3 suspend attempts) when S3 is disabled in QEMU. Public branch: https://github.com/lersek/edk2/commits/drop_efi_acpi_s3_save_proto Cc: Yao Jiewen jiewen@intel.com Cc: Jeff Fan jeff@intel.com Cc: Jordan Justen jordan.l.jus...@intel.com Cc: Ard Biesheuvel ard.biesheu...@linaro.org Cc: David Wei david@intel.com Cc: Tim He tim...@intel.com Thanks Laszlo Ard Biesheuvel (1): IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3-S3Save() call Laszlo Ersek (8): IntelFrameworkModulePkg: AcpiS3SaveDxe: prepare for End-of-Dxe callback IntelFrameworkModulePkg: AcpiS3SaveDxe: call S3Ready() at End-of-Dxe OvmfPkg: AcpiS3SaveDxe: prepare for End-of-Dxe callback OvmfPkg: AcpiS3SaveDxe: call S3Ready() at End-of-Dxe Vlv2TbltDevicePkg: replace AcpiS3Save-S3Save() with End-of-Dxe signal OvmfPkg: reorganize (but don't reorder) S3 save state
Re: [edk2] [PATCH v2 02/24] PcAtChipsetPkg: remove PciHostBridgeDxe
On 2015-06-25 21:26:20, Ni, Ruiyu wrote: Jordan, Simply using PCD to split the code is very straightforward. Another approach is to introduce a new library class with carefully defined library APIs so that different platforms can use one common driver plus different instances of libraries. After all, abstracting is never a easy work. So let's firstly make OVMF work by duplicating a PciHostBridgeDxe. Is this the preferred method of making progress then? Duplicate code first, then figure out how to make it more general? I don't see drivers duplicated all that often, so it seems a little strange. I haven't heard you say the PCD idea can't work, so can you spend a little more time considering it to see if it seems reasonable to you? If you are still concerned about the PCDs, then fine we'll just duplicate the code. And, Laszlo, is this really that urgent that you'd rather duplicate a driver under the platform rather than allowing for some discussion on a possible common solution? -Jordan What do you think? Laszlo, I don't want to block you. And I do not see a big conflict between you and Jordan. Thank you very much for your continuously code contribution. Thanks, Ray -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Friday, June 26, 2015 3:07 AM To: Justen, Jordan L; Ni, Ruiyu Cc: edk2-devel@lists.sourceforge.net; Kinney, Michael D Subject: Re: [edk2] [PATCH v2 02/24] PcAtChipsetPkg: remove PciHostBridgeDxe Jordan, Ray, On 06/25/15 19:14, Jordan Justen wrote: On 2015-06-24 19:10:01, Ni, Ruiyu wrote: Jordan, I prefer to share the code across multiple platforms as well, if that's possible. In real world, DUET's PciHostBridgeDxe driver does something additionally: it gathers all option roms from PCI devices and transfers them to its own special PciBus driver to dispatch. I am not familiar to OVMF and CorebootPayloadPkg's PciHostBridgeDxe drivers. What specific behaviors do they do? Can we generalize all the special behaviors to a common driver? I do NOT like to introduce a bunch of PCDs like PcdDuet, PcdOvmf and PcdCoreboot. I think the names would not need to include the platform names. For this case, it seems like 1 or 2 PCDs would be sufficient: * PcdScanForAdditionalPciRootBuses (boolean / feature PCD) * PcdAdditionalRootBusesMaxBusNumber We could also only have 1 PCD (PcdAdditionalRootBusesMaxBusNumber) and set it to 0 to disable the feature. here's my respectful request for the two of you: Please work out an agreement between the two of you, by the end of next week, Friday, July 3rd, 2015, End-of-Business, in Jordan's timezone. (Reminder: the first version of the series (with practically identical PciHostBridgeDxe impact) has been posted on June 6th, 19 days ago.) I have already agreed to both of your designs, but I can't satisfy both at once, because your requirements conflict with each other. I'm (obviously) willing to implement what Ray suggests. I'm also willing to implement Jordan's suggestion, but then I will need some form of *commitment* from Ray in advance. Namely, I said earlier, and I'm saying again, that the *overwhelming majority* of the series applies immediately to the driver in PcAtChipsetPkg, therefore Ray can review those patches right now, on a higher level, and express if he agrees with those patches ending up under PcAtChipsetPkg. I will be on PTO next week. If you can reach an agreement until next Friday, I will do my best after, to implement that shared design of yours. If the two of you can't reach an agreement until next Friday, I will abandon this series publicly, and we will carry it downstream only. Thanks Laszlo -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] Add virtio-vga support
On 2015-06-23 05:52:51, Laszlo Ersek wrote:
On 06/23/15 14:36, Gerd Hoffmann wrote:
The vga compatibility part of virtio-vga is identical to the qemu
standard vga, so supporting that is as easy as adding the PCI ID
to the list.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
OvmfPkg/QemuVideoDxe/Driver.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index c74d1a2..8d962b4 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -53,6 +53,11 @@ QEMU_VIDEO_CARD gQemuVideoCardList[] = {
QEMU_VIDEO_BOCHS,
LQEMU QXL VGA
},{
+0x1af4,
+0x1050,
+QEMU_VIDEO_BOCHS_MMIO,
+LQEMU VirtIO VGA
+},{
0 /* end of list */
}
};
Can you please name the qemu commit (or one of the commits) that adds
the device model?
Plus, the subject should say:
OvmfPkg: QemuVideoDxe: add virtio-vga support
I'll update the commit message for you.
Reviewed-by: Laszlo Ersek ler...@redhat.com
First let's give Jordan a chance to look at this though.
Acked-by: Jordan Justen jordan.l.jus...@intel.com
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical virtual servers, alerts via email sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v2 4/4] OvmfPkg: PlatformPei: invert MTRR setup in QemuInitializeRam()
On 2015-06-23 12:53:49, Laszlo Ersek wrote:
At the moment we work with a UC default MTRR type, and set three memory
ranges to WB:
- [0, 640 KB),
- [1 MB, LowerMemorySize),
- [4 GB, 4 GB + UpperMemorySize).
Unfortunately, coverage for the third range can fail with a high
likelihood. If the alignment of the base (ie. 4 GB) and the alignment of
the size (UpperMemorySize) differ, then MtrrLib creates a series of
variable MTRR entries, with power-of-two sized MTRR masks. And, it's
really easy to run out of variable MTRR entries, dependent on the
alignment difference.
This is a problem because a Linux guest will loudly reject any high memory
that is not covered my MTRR.
So, let's follow the inverse pattern (loosely inspired by SeaBIOS):
- flip the MTRR default type to WB,
- set [0, 640 KB) to WB -- fixed MTRRs have precedence over the default
type and variable MTRRs, so we can't avoid this,
- set [640 KB, 1 MB) to UC -- implemented with fixed MTRRs,
- set [LowerMemorySize, 4 GB) to UC -- should succeed with variable MTRRs
more likely than the other scheme (due to less chaotic alignment
differences).
Effects of this patch can be observed by setting DEBUG_CACHE (0x0020)
in PcdDebugPrintErrorLevel.
Cc: Maoming maoming.maom...@huawei.com
Cc: Huangpeng (Peter) peter.huangp...@huawei.com
Cc: Wei Liu wei.l...@citrix.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
Tested-by: Maoming maoming.maom...@huawei.com
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
---
Notes:
v2:
- update comments [Jordan]
- calculate the size of the low 384 KB uncacheable hole as Jordan
suggested
OvmfPkg/PlatformPei/MemDetect.c | 46 ++--
1 file changed, 42 insertions(+), 4 deletions(-)
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index b74308f..4778a55 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -252,6 +252,8 @@ QemuInitializeRam (
{
UINT64 LowerMemorySize;
UINT64 UpperMemorySize;
+ MTRR_SETTINGS MtrrSettings;
+ EFI_STATUS Status;
DEBUG ((EFI_D_INFO, %a called\n, __FUNCTION__));
@@ -272,12 +274,48 @@ QemuInitializeRam (
}
}
- MtrrSetMemoryAttribute (BASE_1MB, LowerMemorySize - BASE_1MB,
CacheWriteBack);
+ //
+ // We'd like to keep the following ranges uncached:
+ // - [640 KB, 1 MB)
+ // - [LowerMemorySize, 4 GB)
+ //
+ // Everything else should be WB. Unfortunately, programming the inverse
(ie.
+ // keeping the default UC, and configuring the complement set of the above
as
+ // WB) is not reliable in general, because the end of the upper RAM can
have
+ // practically any alignment, and we may not have enough variable MTRRs to
+ // cover it exactly.
+ //
+ if (IsMtrrSupported ()) {
+MtrrGetAllMtrrs (MtrrSettings);
- MtrrSetMemoryAttribute (0, BASE_512KB + BASE_128KB, CacheWriteBack);
+//
+// MTRRs disabled, fixed MTRRs disabled, default type is uncached
+//
+ASSERT ((MtrrSettings.MtrrDefType BIT11) == 0);
+ASSERT ((MtrrSettings.MtrrDefType BIT10) == 0);
+ASSERT ((MtrrSettings.MtrrDefType 0xFF) == 0);
- if (UpperMemorySize != 0) {
-MtrrSetMemoryAttribute (BASE_4GB, UpperMemorySize, CacheWriteBack);
+//
+// flip default type to writeback
+//
+SetMem (MtrrSettings.Fixed, sizeof MtrrSettings.Fixed, 0x06);
+ZeroMem (MtrrSettings.Variables, sizeof MtrrSettings.Variables);
+MtrrSettings.MtrrDefType |= BIT11 | BIT10 | 6;
+MtrrSetAllMtrrs (MtrrSettings);
+
+//
+// Set memory from 640KB to 1MB to uncacheable
+//
Thanks Laszlo. All the patches look good to me now.
If I have a nit pick remaining, it would be the comments I suggested
here. :)
I think maybe 'memory' = 'memory range' seems better. What do you
think?
+Status = MtrrSetMemoryAttribute (BASE_512KB + BASE_128KB,
+ BASE_1MB - (BASE_512KB + BASE_128KB), CacheUncacheable);
+ASSERT_EFI_ERROR (Status);
+
+//
+// Set MMIO just below 4GB to uncacheable
+//
You expressed some doubts about this, and I agree. To throw out
another option, maybe:
//
// Set memory range from the top of lower RAM (RAM below 4GB) to
// 4GB as uncacheable
//
Or, maybe:
//
// Set memory range for memory mapped IO below 4GB as uncacheable
//
Or, perhaps you have a better suggestion?
Anyway, I don't think it is critical, so with or without changes,
series Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
+Status = MtrrSetMemoryAttribute (LowerMemorySize,
+ SIZE_4GB - LowerMemorySize, CacheUncacheable);
+ASSERT_EFI_ERROR (Status);
}
}
--
1.8.3.1
Re: [edk2] [PATCH 4/4] OvmfPkg: PlatformPei: invert MTRR setup in QemuInitializeRam()
On 2015-06-16 10:05:27, Laszlo Ersek wrote:
At the moment we work with a UC default MTRR type, and set three memory
ranges to WB:
- [0, 640 KB),
- [1 MB, LowerMemorySize),
- [4 GB, 4 GB + UpperMemorySize).
Unfortunately, coverage for the third range can fail with a high
likelihood. If the alignment of the base (ie. 4 GB) and the alignment of
the size (UpperMemorySize) differ, then MtrrLib creates a series of
variable MTRR entries, with power-of-two sized MTRR masks. And, it's
really easy to run out of variable MTRR entries, dependent on the
alignment difference.
This is a problem because a Linux guest will loudly reject any high memory
that is not covered my MTRR.
So, let's follow the inverse pattern (loosely inspired by SeaBIOS):
- flip the MTRR default type to WB,
- set [0, 640 KB) to WB -- fixed MTRRs have precedence over the default
type and variable MTRRs, so we can't avoid this,
- set [640 KB, 1 MB) to UC -- implemented with fixed MTRRs,
- set [LowerMemorySize, 4 GB) to UC -- should succeed with variable MTRRs
more likely than the other scheme (due to less chaotic alignment
differences).
Effects of this patch can be observed by setting DEBUG_CACHE (0x0020)
in PcdDebugPrintErrorLevel.
Cc: Maoming maoming.maom...@huawei.com
Cc: Huangpeng (Peter) peter.huangp...@huawei.com
Cc: Wei Liu wei.l...@citrix.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
Tested-by: Maoming maoming.maom...@huawei.com
---
OvmfPkg/PlatformPei/MemDetect.c | 43
+
1 file changed, 39 insertions(+), 4 deletions(-)
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 1228063..e872126 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -194,6 +194,8 @@ QemuInitializeRam (
{
UINT64 LowerMemorySize;
UINT64 UpperMemorySize;
+ MTRR_SETTINGS MtrrSettings;
+ EFI_STATUS Status;
DEBUG ((EFI_D_INFO, %a called\n, __FUNCTION__));
@@ -214,12 +216,45 @@ QemuInitializeRam (
}
}
- MtrrSetMemoryAttribute (BASE_1MB, LowerMemorySize - BASE_1MB,
CacheWriteBack);
+ //
+ // We'd like to keep the following ranges uncached:
+ // - [640 KB, 1 MB)
+ // - [LowerMemorySize, 4 GB)
+ //
+ // Everything else should be WB. Unfortunately, programming the inverse
(ie.
+ // keeping the default UC, and configuring the complement set of the above
as
+ // WB) is not reliable in general, because the end of the upper RAM can
have
+ // practically any alignment, and we may not have enough variable MTRRs to
+ // cover it exactly.
+ //
+ if (IsMtrrSupported ()) {
+MtrrGetAllMtrrs (MtrrSettings);
- MtrrSetMemoryAttribute (0, BASE_512KB + BASE_128KB, CacheWriteBack);
+//
+// MTRRs disabled, fixed MTRRs disabled, default type is uncached
+//
+ASSERT ((MtrrSettings.MtrrDefType BIT11) == 0);
+ASSERT ((MtrrSettings.MtrrDefType BIT10) == 0);
+ASSERT ((MtrrSettings.MtrrDefType 0xFF) == 0);
- if (UpperMemorySize != 0) {
-MtrrSetMemoryAttribute (BASE_4GB, UpperMemorySize, CacheWriteBack);
+//
+// flip default type to writeback
+//
+SetMem (MtrrSettings.Fixed, sizeof MtrrSettings.Fixed, 0x06);
+ZeroMem (MtrrSettings.Variables, sizeof MtrrSettings.Variables);
+MtrrSettings.MtrrDefType |= BIT11 | BIT10 | 6;
+MtrrSetAllMtrrs (MtrrSettings);
+
+//
+// punch holes
What about: Set memory from 640KB - 1MB to uncacheable
+//
+Status = MtrrSetMemoryAttribute (BASE_512KB + BASE_128KB,
+ SIZE_256KB + SIZE_128KB, CacheUncacheable);
What about instead specifying length as:
BASE_1MB - (BASE_512KB + BASE_128KB)
+ASSERT_EFI_ERROR (Status);
+
How about a comment: Set MMIO just below 4GB to uncacheable
+Status = MtrrSetMemoryAttribute (LowerMemorySize,
+ SIZE_4GB - LowerMemorySize, CacheUncacheable);
+ASSERT_EFI_ERROR (Status);
Patches 2-4:
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
}
}
--
1.8.3.1
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical virtual servers, alerts via email sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https
Re: [edk2] [PATCH 1/4] OvmfPkg: PlatformPei: enable larger permanent PEI RAM
On 2015-06-22 12:22:54, Brian J. Johnson wrote: I stuck those calculations in gnumeric (assuming Page1GSupport==FALSE) and got this: PABits Pml4Pdp TotPgs MB -- --- -- -- 36 1 64 66 0.258 37 1 128 130 0.508 38 1 256 258 1.008 39 1 512 514 2.008 40 2 512 10274.012 41 4 512 20538.020 42 8 512 410516.035 43 16 512 820932.066 44 32 512 16417 64.129 45 64 512 32833 128.254 46 128 512 65665 256.504 47 256 512 131329 513.004 48 512 512 262657 1026.004 So 48 bits of PA should take just over a GB of page tables. Can you set PcdUse1GPageTable=TRUE? That vastly reduces the number of page table pages needed, and vastly reduces the time needed to initialize them. Just wondering. (I've found that some older Microsoft boot loaders don't like this setting, but I haven't tried the newer ones. Linux is fine with it.) Sound kind of complicated to tell if it is okay to use. Although, maybe if we just use it dynamically when memory space is larger than say 36 bits, then perhaps the risk of people running an unsupported configuration is also low. -Jordan -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH 1/4] OvmfPkg: PlatformPei: enable larger permanent PEI RAM
On 2015-06-16 10:05:24, Laszlo Ersek wrote:
We'll soon increase the maximum guest-physical RAM size supported by OVMF.
For more RAM, the DXE IPL is going to build more page tables, and for that
it's going to need a bigger chunk from the permanent PEI RAM.
Otherwise CreateIdentityMappingPageTables() would fail with:
DXE IPL Entry
Loading PEIM at 0x000BFF61000 EntryPoint=0x000BFF61260 DxeCore.efi
Loading DXE CORE at 0x000BFF61000 EntryPoint=0x000BFF61260
AllocatePages failed: No 0x40201 Pages is available.
There is only left 0x3F1F pages memory resource to be allocated.
ASSERT .../MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c(123):
BigPageAddress != 0
(The above example belongs to the artificially high, maximal address width
of 52, clamped by the DXE core to 48. The address width of 48 bits
corresponds to 256 TB or RAM, and requires a bit more than 1GB for paging
structures.)
Cc: Maoming maoming.maom...@huawei.com
Cc: Huangpeng (Peter) peter.huangp...@huawei.com
Cc: Wei Liu wei.l...@citrix.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
Tested-by: Wei Liu wei.l...@citrix.com
Tested-by: Maoming maoming.maom...@huawei.com
---
OvmfPkg/PlatformPei/Platform.h | 7 +
OvmfPkg/PlatformPei/MemDetect.c | 61
+++--
OvmfPkg/PlatformPei/Platform.c | 1 +
3 files changed, 66 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/PlatformPei/Platform.h b/OvmfPkg/PlatformPei/Platform.h
index 31640e9..8b6a976 100644
--- a/OvmfPkg/PlatformPei/Platform.h
+++ b/OvmfPkg/PlatformPei/Platform.h
@@ -59,6 +59,11 @@ AddUntestedMemoryRangeHob (
EFI_PHYSICAL_ADDRESSMemoryLimit
);
+VOID
+AddressWidthInitialization (
+ VOID
+ );
+
EFI_STATUS
PublishPeiMemory (
VOID
@@ -100,4 +105,6 @@ extern EFI_BOOT_MODE mBootMode;
extern BOOLEAN mS3Supported;
+extern UINT8 mPhysMemAddressWidth;
+
#endif // _PLATFORM_PEI_H_INCLUDED_
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index bd7bb02..6b424f7 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -36,6 +36,8 @@ Module Name:
#include Platform.h
#include Cmos.h
+UINT8 mPhysMemAddressWidth;
+
UINT32
GetSystemMemorySizeBelow4gb (
VOID
@@ -84,6 +86,47 @@ GetSystemMemorySizeAbove4gb (
return LShiftU64 (Size, 16);
}
+
+/**
+ Initialize the mPhysMemAddressWidth variable, based on guest RAM size.
+**/
+VOID
+AddressWidthInitialization (
+ VOID
+ )
+{
+ UINT64 FirstNonAddress;
+
+ //
+ // As guest-physical memory size grows, the permanent PEI RAM requirements
+ // are dominated by the identity-mapping page tables built by the DXE IPL.
+ // The DXL IPL keys off of the physical address bits advertized in the CPU
+ // HOB. To conserve memory, we calculate the minimum address width here.
+ //
+ FirstNonAddress = BASE_4GB + GetSystemMemorySizeAbove4gb ();
+ mPhysMemAddressWidth = (UINT8)HighBitSet64 (FirstNonAddress);
+
+ //
+ // If FirstNonAddress is not an integral power of two, then we need an
+ // additional bit.
+ //
+ if ((FirstNonAddress (FirstNonAddress - 1)) != 0) {
+++mPhysMemAddressWidth;
+ }
+
+ //
+ // The minimum address width is 36 (covers up to and excluding 64 GB, which
+ // is the maximum for Ia32 + PAE). The theoretical architecture maximum for
+ // X64 long mode is 52 bits, but the DXE IPL clamps that down to 48 bits.
We
+ // can simply assert that here, since 48 bits are good enough for 256 TB.
+ //
+ if (mPhysMemAddressWidth = 36) {
+mPhysMemAddressWidth = 36;
+ }
+ ASSERT (mPhysMemAddressWidth = 48);
+}
+
+
/**
Publish PEI core memory
@@ -99,6 +142,7 @@ PublishPeiMemory (
EFI_PHYSICAL_ADDRESSMemoryBase;
UINT64 MemorySize;
UINT64 LowerMemorySize;
+ UINT32 PeiMemoryCap;
if (mBootMode == BOOT_ON_S3_RESUME) {
MemoryBase = PcdGet32 (PcdS3AcpiReservedMemoryBase);
@@ -107,13 +151,24 @@ PublishPeiMemory (
LowerMemorySize = GetSystemMemorySizeBelow4gb ();
//
+// For the minimum address width of 36, installing 64 MB as permanent PEI
+// RAM is sufficient. For the maximum width, the DXE IPL needs a bit more
+// than 1 GB for paging structures. Therefore we establish an exponential
+// formula so that the 48-36+1=13 different widths map to permanent PEI
RAM
+// sizes in [64 MB, 2 GB], that is [126, 131]; 6 different powers.
+//
+PeiMemoryCap = SIZE_64MB ((mPhysMemAddressWidth - 36) * 5 / 12);
In the python interpreter, I wrote:
for p in map(lambda a: (a, 64 ((a-36) * 5 / 12)), range(36,49)): print
'%d bits = %d MB' % p
...
36 bits = 64 MB
37 bits = 64 MB
38 bits = 64 MB
39 bits = 128 MB
40 bits = 128 MB
41 bits = 256 MB
42 bits = 256 MB
43 bits = 256 MB
44 bits
Re: [edk2] [PATCH 1/4] OvmfPkg: PlatformPei: enable larger permanent PEI RAM
On 2015-06-22 12:07:05, Laszlo Ersek wrote: On 06/22/15 20:34, Jordan Justen wrote: What if you make a calculation of how big the tables should be and then add 64 MB to it? Any calculation I could come up with (ie. how much RAM *I* would need for identity mapping the address sapce) would not be any better than the above empirical formula -- because whatever I'd invent might not bear any resemblance to how the actual allocation happens. I don't think this is the case. The code that does this in DxeIpl doesn't change that often, and it is not too different from other similar firmware/OS code. It seems a lot more intuitive to me to say something like: we need a big blob of memory for page tables (see DxeIpl), and then about 64MB more for misc -Jordan -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] OvmfPkg: PlatformPei: set SMBIOS entry point version dynamically
On 2015-06-19 16:40:51, Laszlo Ersek wrote:
Git commit 54753b60 (SVN r16870), MdeModulePkg: Update SMBIOS revision to
3.0. changed PcdSmbiosVersion from 0x0208 to 0x0300. This controls the
version number of the SMBIOS entry point table (and other things) that
MdeModulePkg/Universal/SmbiosDxe installs.
Alas, this change breaks older Linux guests, like RHEL-6 (up to RHEL-6.7);
How does it break them? It seems a bit odd that the firmware could
break the OS by upgrading its SMBIOS version.
Anyway, I think it is good to extract it from QEMU fw-cfg, and I think
for now 2.8 seems a reasonable fall-back default.
I wonder if someone wants to do something similar for Xen?
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
those are limited to 2.x (both in the guest kernel firmware driver, and in
the dmidecode utility).
The v2.1.0+ machine types of QEMU generate SMBIOS payload for the firmware
to install. The payload includes the entry point table (anchor table).
OvmfPkg/SmbiosPlatformDxe cannot install the anchor table (because that is
the jurisdiction of the generic MdeModulePkg/Universal/SmbiosDxe
driver); however, we can parse the entry point version from QEMU's anchor
table, and instruct MdeModulePkg/Universal/SmbiosDxe to adhere to that
version.
On machine types older than v2.1.0, the feature is not available, but
then, should anything in OVMF install SMBIOS tables, version 2.8 is simply
safer / more widely supported than 3.0 -- hence the default 2.8 value for
the dynamic PCD.
We set the PCD in PlatformPei (when not on the S3 resume path), because
that's an easy and certain way to set the PCD before a DXE driver reads
it. This follows the example of PcdEmuVariableNvStoreReserved (which is
read by EmuVariableFvbRuntimeDxe).
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1232876
Cc: Gabriel Somlo so...@cmu.edu
Cc: Jordan Justen jordan.l.jus...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
Notes:
This simple patch is somewhat urgent for RHEL-7.2, please help me by
reviewing it quickly. Thanks!
OvmfPkg/PlatformPei/PlatformPei.inf | 2 ++
OvmfPkg/PlatformPei/Platform.c | 39
+
OvmfPkg/OvmfPkgIa32.dsc | 2 ++
OvmfPkg/OvmfPkgIa32X64.dsc | 2 ++
OvmfPkg/OvmfPkgX64.dsc | 2 ++
5 files changed, 47 insertions(+)
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 0307bca..721495b 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -58,6 +58,7 @@ [LibraryClasses]
QemuFwCfgLib
MtrrLib
PcdLib
+ BaseMemoryLib
[Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase
@@ -81,6 +82,7 @@ [Pcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved
gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
+ gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
[Ppis]
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 2a1b577..fc98fc3 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -32,9 +32,11 @@
#include Library/PeiServicesLib.h
#include Library/QemuFwCfgLib.h
#include Library/ResourcePublicationLib.h
+#include Library/BaseMemoryLib.h
#include Guid/MemoryTypeInformation.h
#include Ppi/MasterBootMode.h
#include IndustryStandard/Pci22.h
+#include IndustryStandard/SmBios.h
#include OvmfPlatforms.h
#include Platform.h
@@ -380,6 +382,41 @@ DebugDumpCmos (
/**
+ Set the SMBIOS entry point version for the generic SmbiosDxe driver.
+**/
+STATIC
+VOID
+SmbiosVersionInitialization (
+ VOID
+ )
+{
+ FIRMWARE_CONFIG_ITEM Anchor;
+ UINTNAnchorSize;
+ SMBIOS_TABLE_ENTRY_POINT QemuAnchor;
+ UINT16 SmbiosVersion;
+
+ if (RETURN_ERROR (QemuFwCfgFindFile (etc/smbios/smbios-anchor, Anchor,
+ AnchorSize)) ||
+ AnchorSize != sizeof QemuAnchor) {
+return;
+ }
+
+ QemuFwCfgSelectItem (Anchor);
+ QemuFwCfgReadBytes (AnchorSize, QemuAnchor);
+ if (CompareMem (QemuAnchor.AnchorString, _SM_, 4) != 0 ||
+ CompareMem (QemuAnchor.IntermediateAnchorString, _DMI_, 5) != 0) {
+return;
+ }
+
+ SmbiosVersion = (UINT16)(QemuAnchor.MajorVersion 8 |
+ QemuAnchor.MinorVersion);
+ DEBUG ((EFI_D_INFO, %a: SMBIOS version from QEMU: 0x%04x\n, __FUNCTION__,
+SmbiosVersion));
+ PcdSet16 (PcdSmbiosVersion, SmbiosVersion);
+}
+
+
+/**
Perform Platform PEI initialization.
@param FileHandle Handle of the file being invoked.
@@ -429,6 +466,8 @@ InitializePlatform (
PeiFvInitialization ();
MemMapInitialization
Re: [edk2] [patch 1/3] [CryptoPkg] Remove the old patch file for openssl-0.9.8zf build, and add the patch file for openssl-1.0.2b.
On 2015-06-12 04:19:09, qlong wrote:
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Long, Qin qin.l...@intel.com
Signed-off-by: qlong qin.l...@intel.com
Your commit message doesn't match the recommended format:
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
(Lines too long. Double signature seems odd.)
Another tip... If you look under Your Identity on:
https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup
Then you can setup your username and email so 'git commit -s' will
automatically add your Signed-off-by.
$ git config --global user.name Qin Long
$ git config --global user.email qin.l...@intel.com
For your commit message, I recommend this change:
You have
[CryptoPkg] Remove the old patch file for openssl-0.9.8zf build, and add the
patch file for openssl-1.0.2b.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Long, Qin qin.l...@intel.com
Signed-off-by: qlong qin.l...@intel.com
I recommend ===
CryptoPkg: Update openssl patch file from 0.9.8zf to 1.0.2b
This patch adds a patch file for openssl-1.0.2b, and removes the patch
file for openssl-0.9.8zf.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Long, Qin qin.l...@intel.com
Can you make similar changes for patches 2 3?
Thanks,
-Jordan
---
.../Library/OpensslLib/EDKII_openssl-0.9.8zf.patch | 279 -
.../Library/OpensslLib/EDKII_openssl-1.0.2b.patch | 346
+
2 files changed, 346 insertions(+), 279 deletions(-)
delete mode 100644 CryptoPkg/Library/OpensslLib/EDKII_openssl-0.9.8zf.patch
create mode 100644 CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2b.patch
diff --git a/CryptoPkg/Library/OpensslLib/EDKII_openssl-0.9.8zf.patch
b/CryptoPkg/Library/OpensslLib/EDKII_openssl-0.9.8zf.patch
deleted file mode 100644
index 4abe62c..000
--- a/CryptoPkg/Library/OpensslLib/EDKII_openssl-0.9.8zf.patch
+++ /dev/null
@@ -1,279 +0,0 @@
-Index: crypto/bio/bss_file.c
-===
crypto/bio/bss_file.c (revision 1)
-+++ crypto/bio/bss_file.c (working copy)
-@@ -418,6 +418,23 @@
- return (ret);
- }
-
-+#else
-+
-+BIO_METHOD *BIO_s_file(void)
-+{
-+return NULL;
-+}
-+
-+BIO *BIO_new_file(const char *filename, const char *mode)
-+{
-+return NULL;
-+}
-+
-+BIO *BIO_new_fp(FILE *stream, int close_flag)
-+{
-+return NULL;
-+}
-+
- # endif /* OPENSSL_NO_STDIO */
-
- #endif /* HEADER_BSS_FILE_C */
-Index: crypto/crypto.h
-===
crypto/crypto.h(revision 1)
-+++ crypto/crypto.h(working copy)
-@@ -239,15 +239,15 @@
- # ifndef OPENSSL_NO_LOCKING
- # ifndef CRYPTO_w_lock
- # define CRYPTO_w_lock(type) \
--CRYPTO_lock(CRYPTO_LOCK|CRYPTO_WRITE,type,__FILE__,__LINE__)
-+CRYPTO_lock(CRYPTO_LOCK|CRYPTO_WRITE,type,NULL,0)
- # define CRYPTO_w_unlock(type) \
--CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_WRITE,type,__FILE__,__LINE__)
-+CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_WRITE,type,NULL,0)
- # define CRYPTO_r_lock(type) \
--CRYPTO_lock(CRYPTO_LOCK|CRYPTO_READ,type,__FILE__,__LINE__)
-+CRYPTO_lock(CRYPTO_LOCK|CRYPTO_READ,type,NULL,0)
- # define CRYPTO_r_unlock(type) \
--CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_READ,type,__FILE__,__LINE__)
-+CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_READ,type,NULL,0)
- # define CRYPTO_add(addr,amount,type)\
--CRYPTO_add_lock(addr,amount,type,__FILE__,__LINE__)
-+CRYPTO_add_lock(addr,amount,type,NULL,0)
- # endif
- # else
- # define CRYPTO_w_lock(a)
-@@ -374,19 +374,19 @@
- # define MemCheck_off() CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE)
- # define is_MemCheck_on() CRYPTO_is_mem_check_on()
-
--# define OPENSSL_malloc(num) CRYPTO_malloc((int)num,__FILE__,__LINE__)
--# define OPENSSL_strdup(str) CRYPTO_strdup((str),__FILE__,__LINE__)
-+# define OPENSSL_malloc(num) CRYPTO_malloc((int)num,NULL,0)
-+# define OPENSSL_strdup(str) CRYPTO_strdup((str),NULL,0)
- # define OPENSSL_realloc(addr,num) \
--CRYPTO_realloc((char *)addr,(int)num,__FILE__,__LINE__)
-+CRYPTO_realloc((char *)addr,(int)num,NULL,0)
- # define OPENSSL_realloc_clean(addr,old_num,num) \
--CRYPTO_realloc_clean(addr,old_num,num,__FILE__,__LINE__)
-+CRYPTO_realloc_clean(addr,old_num,num,NULL,0)
- # define OPENSSL_remalloc(addr,num) \
--CRYPTO_remalloc((char **)addr,(int)num,__FILE__,__LINE__)
-+CRYPTO_remalloc((char **)addr,(int)num,NULL,0)
- # define OPENSSL_freeFuncCRYPTO_free
- # define OPENSSL_free(addr) CRYPTO_free(addr)
-
- # define OPENSSL_malloc_locked(num) \
--CRYPTO_malloc_locked((int)num,__FILE__,__LINE__)
-+
Re: [edk2] [Patch] BaseTools: Update nasmb build rule
On 2015-06-08 18:31:30, Gao, Liming wrote: Jordan: I don't get any feedback from others. You also say I can go ahead. So, I add this change. Ok. You are right. It is true that I said: I don't like the idea of creating the .com for .nasmb sources, but if you insist that it is required, then you can go ahead. So, I guess you went ahead. Can you at least agree that the use of the .com extension is confusing in this case, since .com files are 16-bit DOS executables? I think the only reason they appeared in EDK/EDK II is because masm16 would only output a .com file. I don't think we need to make everything backward compatible. This is a new tool without the legacy masm baggage, so do we really need to go out of our way to bring the masm baggage along? Really, wouldn't it be reasonable for a platform to make a 1-line change to their .fdf file if for no other reason than to make it obvious that a big change just happened to their SEC phase? This project goes *way* out of it's way to try to be backward compatible. In my opinion, often too far. Ok. Rant complete. Thanks for your time, :) -Jordan I add this support for compatibility. I want to update our core module to use .nasmb, and platform can directly use the updated core module without changes. Now, our most platforms use .com postfix in their platform FDF Ffs Rule. With this patch, after we update more core modules to use .nasmb instead .asm16, it will not impact platforms. Thanks Liming -Original Message- From: Justen, Jordan L Sent: Tuesday, June 9, 2015 12:56 AM To: Gao, Liming; edk2-devel@lists.sourceforge.net Subject: RE: [edk2] [Patch] BaseTools: Update nasmb build rule On 2014-11-21 10:16:47, Jordan Justen wrote: On 2014-11-20 22:12:42, Gao, Liming wrote: Jordan: NASMB is replacement of ASM16. I see .nasmb as an alternative, but not a replacement. (.asm16 is still supported by EDK II.) I do hope that long term it replaces all uses of .asm16 though. :) Now, ASM16 has been used in the different modules. When the module owners do this conversion, they expect it is compatible and doesn't impact platform, because module owner can't predict how many platform will be impacted. So, I think the compatibility is the important point to persuade the module owners to do this conversion. I would rather see .bin be used in this case, because it makes more sense than .com. I guess .com was used because it was the output from link16? But, .com files are known as old dos based executables. It is a confusing use of the extension. I see you went ahead and committed this without further discussion. I also see that you converted an internal platform's fdf from being able to accept either .bin or .com to only accept .com. So, apparently you have real preference for using .com rather than .bin. Can you explain why you think .com makes better sense than .bin in this context? http://en.wikipedia.org/wiki/COM_file -Jordan If we copy the file like in your patch, then few platforms will actually change from using .com to .bin, but I think it would be an improvement for them to convert to using the .bin extension. Maybe another idea is to leave the .asm16 .inf in place, and create a new .inf with the .nasmb source. Then the platform will have to change both the .dsc and .fdf to make use of NASM. This will also leave the platform with the option to continue using MASM16/LINK16. I don't like the idea of creating the .com for .nasmb sources, but if you insist that it is required, then you can go ahead. I will not give my r-b for the change though. :) -Jordan -Original Message- From: Justen, Jordan L Sent: Friday, November 21, 2014 12:58 PM To: edk2-devel@lists.sourceforge.net; Gao, Liming Subject: Re: [edk2] [Patch] BaseTools: Update nasmb build rule On 2014-11-18 23:49:45, Gao, Liming wrote: Nasmb can replace ASM16. Now, ASM16 output file is *.com. To be compatible with it, update nasmb build rule to output *.com file also. ASM16 output file is used by Platform FDF Rule section. With this patch, Platform FDF file will not be impacted after asm16 file is converted to nasmb file. Liming, I don't think we need this change. With a small change to the .fdf, .bin can work as easily as .com. I think .com was a bad extension for this file, even when masm16/link16 was being used. Maybe we should have copied from .com to .bin before. -Jordan Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao liming@intel.com --- Index: build_rule.template == = --- build_rule.template (revision 16400) +++ build_rule.template (working copy) @@ -491,8
Re: [edk2] [PATCH v5 2/2] OvmfPkg/PlatformPei: Initialise RCBA (B0:D31:F0 0xf0) register
Series Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
and committed. Thanks for the contribution!
On 2015-06-08 17:16:14, Paulo Alcantara wrote:
This patch initialises root complex register block BAR in order to
support TCO watchdog emulation features (e.g. reboot upon NO_REBOOT bit
not set) on QEMU.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paulo Alcantara pca...@zytor.com
---
OvmfPkg/Include/IndustryStandard/Q35MchIch9.h | 5 +
OvmfPkg/PlatformPei/Platform.c| 17 -
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
index 4f59a7c..18b34a3 100644
--- a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
+++ b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
@@ -77,6 +77,9 @@
#define ICH9_GEN_PMCON_1 0xA0
#define ICH9_GEN_PMCON_1_SMI_LOCK BIT4
+#define ICH9_RCBA 0xF0
+#define ICH9_RCBA_ENBIT0
+
//
// IO ports
//
@@ -90,4 +93,6 @@
#define ICH9_SMI_EN_APMC_EN BIT5
#define ICH9_SMI_EN_GBL_SMI_EN BIT0
+#define ICH9_ROOT_COMPLEX_BASE 0xFED1C000
+
#endif
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 0e41d30..1ad5bfc 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -214,13 +214,18 @@ MemMapInitialization (
// 0xFEC0IO-APIC4 KB
// 0xFEC01000gap 1020 KB
// 0xFED0HPET 1 KB
-// 0xFED00400gap 1023 KB
+// 0xFED00400gap 111 KB
+// 0xFED1C000gap (PIIX4) / RCRB (ICH9) 16 KB
+// 0xFED2gap 896 KB
// 0xFEE0LAPIC 1 MB
//
AddIoMemoryRangeHob (TopOfLowRam BASE_2GB ?
BASE_2GB : TopOfLowRam, 0xFC00);
AddIoMemoryBaseSizeHob (0xFEC0, SIZE_4KB);
AddIoMemoryBaseSizeHob (0xFED0, SIZE_1KB);
+if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
+ AddIoMemoryBaseSizeHob (ICH9_ROOT_COMPLEX_BASE, SIZE_16KB);
+}
AddIoMemoryBaseSizeHob (PcdGet32(PcdCpuLocalApicBaseAddress), SIZE_1MB);
}
}
@@ -292,6 +297,16 @@ MiscInitialization (
//
PciOr8 (AcpiCtlReg, AcpiEnBit);
}
+
+ if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
+//
+// Set Root Complex Register Block BAR
+//
+PciWrite32 (
+ POWER_MGMT_REGISTER_Q35 (ICH9_RCBA),
+ ICH9_ROOT_COMPLEX_BASE | ICH9_RCBA_EN
+ );
+ }
}
--
2.1.0
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTools: Update nasmb build rule
On 2015-06-09 02:38:02, Gao, Liming wrote: Jordan: Yes. I agree .bin is better postfix for .nasmb. After we fully migrate .asm16 to .nasmb, I will update our reference platform to use .bin in their FDF Ffs Rules. This sounds like an ok plan. But, then we will have to leave the build-rule copy to a .com file, right? Because now we will have to be backward-compatible with the fact that .nasmb was making .com files for a few months. Sigh... :) Anyway, my suggestion was to make new .inf files for the nasm versions, and convert the platforms to the new .inf and update their .fdf files when changing to the nasm .inf. Then, in the end you can delete the masm .inf files and .asm16 files. -Jordan -Original Message- From: Justen, Jordan L Sent: Tuesday, June 09, 2015 3:12 PM To: Gao, Liming; edk2-devel@lists.sourceforge.net Subject: RE: [edk2] [Patch] BaseTools: Update nasmb build rule On 2015-06-08 18:31:30, Gao, Liming wrote: Jordan: I don't get any feedback from others. You also say I can go ahead. So, I add this change. Ok. You are right. It is true that I said: I don't like the idea of creating the .com for .nasmb sources, but if you insist that it is required, then you can go ahead. So, I guess you went ahead. Can you at least agree that the use of the .com extension is confusing in this case, since .com files are 16-bit DOS executables? I think the only reason they appeared in EDK/EDK II is because masm16 would only output a .com file. I don't think we need to make everything backward compatible. This is a new tool without the legacy masm baggage, so do we really need to go out of our way to bring the masm baggage along? Really, wouldn't it be reasonable for a platform to make a 1-line change to their .fdf file if for no other reason than to make it obvious that a big change just happened to their SEC phase? This project goes *way* out of it's way to try to be backward compatible. In my opinion, often too far. Ok. Rant complete. Thanks for your time, :) -Jordan I add this support for compatibility. I want to update our core module to use .nasmb, and platform can directly use the updated core module without changes. Now, our most platforms use .com postfix in their platform FDF Ffs Rule. With this patch, after we update more core modules to use .nasmb instead .asm16, it will not impact platforms. Thanks Liming -Original Message- From: Justen, Jordan L Sent: Tuesday, June 9, 2015 12:56 AM To: Gao, Liming; edk2-devel@lists.sourceforge.net Subject: RE: [edk2] [Patch] BaseTools: Update nasmb build rule On 2014-11-21 10:16:47, Jordan Justen wrote: On 2014-11-20 22:12:42, Gao, Liming wrote: Jordan: NASMB is replacement of ASM16. I see .nasmb as an alternative, but not a replacement. (.asm16 is still supported by EDK II.) I do hope that long term it replaces all uses of .asm16 though. :) Now, ASM16 has been used in the different modules. When the module owners do this conversion, they expect it is compatible and doesn't impact platform, because module owner can't predict how many platform will be impacted. So, I think the compatibility is the important point to persuade the module owners to do this conversion. I would rather see .bin be used in this case, because it makes more sense than .com. I guess .com was used because it was the output from link16? But, .com files are known as old dos based executables. It is a confusing use of the extension. I see you went ahead and committed this without further discussion. I also see that you converted an internal platform's fdf from being able to accept either .bin or .com to only accept .com. So, apparently you have real preference for using .com rather than .bin. Can you explain why you think .com makes better sense than .bin in this context? http://en.wikipedia.org/wiki/COM_file -Jordan If we copy the file like in your patch, then few platforms will actually change from using .com to .bin, but I think it would be an improvement for them to convert to using the .bin extension. Maybe another idea is to leave the .asm16 .inf in place, and create a new .inf with the .nasmb source. Then the platform will have to change both the .dsc and .fdf to make use of NASM. This will also leave the platform with the option to continue using MASM16/LINK16. I don't like the idea of creating the .com for .nasmb sources, but if you insist that it is required, then you can go ahead. I will not give my r-b for the change though. :) -Jordan -Original Message- From: Justen, Jordan L Sent: Friday, November 21, 2014 12:58 PM To: edk2-devel@lists.sourceforge.net; Gao, Liming Subject: Re: [edk2] [Patch] BaseTools: Update nasmb build rule
Re: [edk2] [PATCH 00/21] OvmfPkg: support extra PCI root buses
On 2015-06-08 00:51:27, Laszlo Ersek wrote: On 06/07/15 06:51, Jordan Justen wrote: On 2015-06-05 16:47:40, Laszlo Ersek wrote: The first 9 patches are uninteresting (although they certainly decimated my grey matter): - Patch #1 copies PciHostBridgeDxe from PcAtChipsetPkg to OvmfPkg. Arg. After I have bugged the DuetPkg and CorebootPayloadPkg package owners to try to fixup PcAtChipsetPkg/PciHostBridgeDxe so all 3 platforms could potentially use it... As far as I know, no one else is using PcAtChipsetPkg/PciHostBridgeDxe right now, so if OVMF stops, then, I think, the attempt to make a common driver in PcAtChipsetPkg has become a failure, and it should be deleted. I can add such a patch, but its acceptance would depend on Ray. So, do I need to read between the lines and assume a part of your motivation for moving the driver is to avoid being dependent on acceptance from Ray for your patches? :) Regarding this driver, it was adding in 2009 / 21b404d for OVMF. I'm still not aware of another platform which uses the driver. But I've been trying to migrate OvmfPkg and DuetPkg to use common drivers where possible. (Example: b8781a7) In fact, many of the original PcAtChipsetPkg drivers came from DuetPkg so they could be used by both DuetPkg and OvmfPkg. That will leave CorebootPayloadPkg still using the DuetPkg one, and no path to resolve that odd situation. I'm not sure this is odd. Host bridge / root bus drivers are supposed to be platform specific. First, I would say they generally are chipset 'north bridge' specific, and not platform specific. (Based on this, OVMF might have a good argument for making this platform specific, since it supports multiple north bridges. But, 440fx vs. q35 is not a factor at this point.) Second, the fact that CorebootPayloadPkg depends on another platform's driver is what seems odd to me. I don't think DuetPkg should be an 'upstream' package for CorebootPayloadPkg. :) I do agree that a good part of the code could be shared between the implementations. We usually have two ways for that: - extracting a library class providing several instances - using multiple INF files (with different source file sets) in the same directory, and/or arch dependent INF file sections. Or, adding a PCD. For example, to through out an idea, what about adding a PcdScanAdditionalPciRootBusesCount integer PCD with a default of 0? Then the changes would generally be a no-op, but QEMU could set the PCD to a higher value based on the fw-cfg value. This might also help keep the changes as a no-op for Xen OVMF. I should say that I'm just throwing out an idea here, for the purpose of discussion. If it seems reasonable, and potentially still leaves the door open for DuetPkg and CorebootPayloadPkg to all use the same driver in the future, then maybe it is worthwhile. I should also say that I'm getting pretty tired of being the only one trying get these platforms to use common code. So, while I would be dissappointed to see this driver killed in the common location, at least I could stop stressing over it. :) -Jordan You don't like the library class approach, as far as my experience goes (plus, the library interface would be quite arbitrary / awkward). The arch-specific INF file sections are not appropriate, because we have differences between the x86-targeted drivers. Finally, using multiple INF files in the same subdirectory would imply the same top-level Pkg directory as well, and that would require either the addition of fw_cfg code to PcAtChipsetPkg, or (in the reverse direction) non-virt packages to reach under (ie. depend on) OvmfPkg. So, what of this is OVMF specific? As I wrote, patches 2 to 9 are just reformatting and could be done in place. I didn't do that up-front because I thought Ray would not be enthusiastic about reviewing 8 sizeable patches that add no features nor bugfixes to PcAtChipsetPkg. Actually, all of the PciHostBridgeDxe patches except the last two could go under PcAtChipsetPkg. The penultimate patch (the brute-force probing) should work on physical hardware as well, but without the fw_cfg enlightenment in the last patch, the performance hit is probably not ideal. Also, it's been said on the list that host bridge / root bus identification is platform specific and frequently hard-coded, so the scanning might not make sense for a physical platform at all. And, of course, all of the prep patches lead up to the last two, so you could argue the series (without the last two patches) would be useless for PcAtChipsetPkg. Aside from fw-cfg patch, I think the method scanning for other root-bridges in OvmfPkg: PciHostBridgeDxe: look for all root buses might be OVMF specific. Looking for devices on other buses seems like a platform specific way of doing that. The VendorId check per se appears to be an industry practice, independent of virtualization: http://www.tldp.org/LDP/tlk/dd
Re: [edk2] [PATCH] OvmfPkg/PlatformPei: Initialise RCBA (B0:D31:F0 0xf0) register
On 2015-06-08 02:06:40, Laszlo Ersek wrote: On 06/06/15 21:10, Paulo Alcantara wrote: diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec index 4cb70dc..a6586f3 100644 --- a/OvmfPkg/OvmfPkg.dec +++ b/OvmfPkg/OvmfPkg.dec @@ -78,6 +78,10 @@ # to PIIX4 function 3 offset 0x40-0x43 bits [15:6]. gUefiOvmfPkgTokenSpaceGuid.PcdAcpiPmBaseAddress|0xB000|UINT16|5 + ## This flag determines the Root Complex Register Block BAR, written to Q35 + # function 31 offset 0xf0-0xf3 bits [31:14] + gUefiOvmfPkgTokenSpaceGuid.PcdRootComplexBaseAddress|0xfed1c000|UINT32|0x1e + I understand Jordan doesn't like the new PCD here, and proposes a fixed macro for the same purpose, but I don't understand why we should follow a different avenue for this base address when we opted for a PCD with the PMBA. I'm not sure there is a good reason for the PMBA PCD at this point. Do you remember why we decided to add a PCD? It doesn't actually change values. I wonder if we were only half committed to the 0x400 = 0xb000 value change at that point? :) I could also see adding a PCD if it looks better for some 'common' code to key off of the PCD, rather than including a chipset specific include file. -Jordan -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v3] OvmfPkg/PlatformPei: Initialise RCBA (B0:D31:F0 0xf0) register
On 2015-06-08 15:07:13, Paulo Alcantara wrote:
This patch initialises root complex register block BAR in order to
support TCO watchdog emulation features (e.g. reboot upon NO_REBOOT bit
not set) on QEMU.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paulo Alcantara pca...@zytor.com
---
OvmfPkg/Include/IndustryStandard/Q35MchIch9.h | 5 +
OvmfPkg/PlatformPei/Platform.c| 14 +-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
index 4f59a7c..18b34a3 100644
--- a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
+++ b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
@@ -77,6 +77,9 @@
#define ICH9_GEN_PMCON_1 0xA0
#define ICH9_GEN_PMCON_1_SMI_LOCK BIT4
+#define ICH9_RCBA 0xF0
+#define ICH9_RCBA_ENBIT0
+
//
// IO ports
//
@@ -90,4 +93,6 @@
#define ICH9_SMI_EN_APMC_EN BIT5
#define ICH9_SMI_EN_GBL_SMI_EN BIT0
+#define ICH9_ROOT_COMPLEX_BASE 0xFED1C000
+
#endif
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 1126c65..3811162 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -212,13 +212,16 @@ MemMapInitialization (
// 0xFEC0IO-APIC4 KB
// 0xFEC01000gap 1020 KB
// 0xFED0HPET 1 KB
-// 0xFED00400gap 1023 KB
+// 0xFED00400gap 111 KB
+// 0xFED1C000RCRB 16 KB
Should we make this conditional?
// 0xFED1C000gap (PIIX4) / RCRB (ICH9) 16 KB
... and make mHostBridgeDevId a global var, and then conditionally add
the memory io HOB?
I don't think it is critical, but with that
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
-Jordan
+// 0xFED2gap 896 KB
// 0xFEE0LAPIC 1 MB
//
AddIoMemoryRangeHob (TopOfLowRam BASE_2GB ?
BASE_2GB : TopOfLowRam, 0xFC00);
AddIoMemoryBaseSizeHob (0xFEC0, SIZE_4KB);
AddIoMemoryBaseSizeHob (0xFED0, SIZE_1KB);
+AddIoMemoryBaseSizeHob (ICH9_ROOT_COMPLEX_BASE, SIZE_16KB);
AddIoMemoryBaseSizeHob (PcdGet32(PcdCpuLocalApicBaseAddress), SIZE_1MB);
}
}
@@ -292,6 +295,15 @@ MiscInitialization (
//
PciOr8 (AcpiCtlReg, AcpiEnBit);
}
+
+ if (HostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
+//
+// Set Root Complex Register Block BAR
+//
+PciWrite32 (POWER_MGMT_REGISTER_Q35 (ICH9_RCBA),
+ICH9_ROOT_COMPLEX_BASE | ICH9_RCBA_EN
+ );
+ }
}
--
2.1.0
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTools: Update nasmb build rule
On 2014-11-21 10:16:47, Jordan Justen wrote:
On 2014-11-20 22:12:42, Gao, Liming wrote:
Jordan:
NASMB is replacement of ASM16.
I see .nasmb as an alternative, but not a replacement. (.asm16 is
still supported by EDK II.)
I do hope that long term it replaces all uses of .asm16 though. :)
Now, ASM16 has been used in the
different modules. When the module owners do this conversion, they
expect it is compatible and doesn't impact platform, because
module owner can't predict how many platform will be impacted. So,
I think the compatibility is the important point to persuade the
module owners to do this conversion.
I would rather see .bin be used in this case, because it makes more
sense than .com. I guess .com was used because it was the output from
link16? But, .com files are known as old dos based executables. It is
a confusing use of the extension.
I see you went ahead and committed this without further discussion.
I also see that you converted an internal platform's fdf from being
able to accept either .bin or .com to only accept .com. So, apparently
you have real preference for using .com rather than .bin.
Can you explain why you think .com makes better sense than .bin in
this context?
http://en.wikipedia.org/wiki/COM_file
-Jordan
If we copy the file like in your patch, then few platforms will
actually change from using .com to .bin, but I think it would be an
improvement for them to convert to using the .bin extension.
Maybe another idea is to leave the .asm16 .inf in place, and create a
new .inf with the .nasmb source. Then the platform will have to change
both the .dsc and .fdf to make use of NASM. This will also leave the
platform with the option to continue using MASM16/LINK16.
I don't like the idea of creating the .com for .nasmb sources, but if
you insist that it is required, then you can go ahead. I will not give
my r-b for the change though. :)
-Jordan
-Original Message-
From: Justen, Jordan L
Sent: Friday, November 21, 2014 12:58 PM
To: edk2-devel@lists.sourceforge.net; Gao, Liming
Subject: Re: [edk2] [Patch] BaseTools: Update nasmb build rule
On 2014-11-18 23:49:45, Gao, Liming wrote:
Nasmb can replace ASM16. Now, ASM16 output file is *.com. To be
compatible with it, update nasmb build rule to output *.com file also.
ASM16 output file is used by Platform FDF Rule section. With this
patch, Platform FDF file will not be impacted after asm16 file is
converted to nasmb file.
Liming,
I don't think we need this change. With a small change to the .fdf, .bin
can work as easily as .com.
I think .com was a bad extension for this file, even when
masm16/link16 was being used. Maybe we should have copied from .com to .bin
before.
-Jordan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao liming@intel.com
---
Index: build_rule.template
===
--- build_rule.template (revision 16400)
+++ build_rule.template (working copy)
@@ -491,8 +491,8 @@
$(PP) $(PP_FLAGS) $(INC) ${src} ${d_path}(+)${s_base}.i
Trim --source-code --convert-hex -o ${d_path}(+)${s_base}.iii
$ {d_path}(+)${s_base}.i
$(NASM) -I${s_path}(+) -l ${d_path}(+)${s_base}.lst
$(NASMB_FLAGS) -o $dst ${d_path}(+)${s_base}.iii
+$(CP) ${dst} $(OUTPUT_DIR)(+)${s_base}.com
-
[Microcode-File.USER_DEFINED, Microcode-File.Microcode]
InputFile
?.txt, ?.TXT, ?.Txt, ?.mut, ?.inc
---
Thanks
Liming
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [patch] MdePkg/PropertiesTable support, MdeModulePkg/DxeCore support UEFI2.5 properties table
On 2015-06-04 10:47:37, Laszlo Ersek wrote: Jiewen, On 06/04/15 16:34, Yao, Jiewen wrote: Hi Here is patch to support UEFI2.5, chapter 4, section 4.6 Properties Table feature. MdePkg \u2013 add Properties table definition. MdeModulePkg \u2013 add properties table support in DXE core. MdeModulePkg \u2013 add PropertiesTableAttributesDxe driver to set ACPINvs/Reserved memory type to be XP. Signed-off-by: Yao, Jiewen jiewen@intel.com mailto:jiewen@intel.com Reviewed-by: Zeng, Star star.z...@intel.com mailto:star.z...@intel.com Reviewed-by: Gao, Liming liming@intel.com mailto:liming@intel.com Honest question: do you ever intend to abandon the following bad practices: - extremely long lines, - huge code bombs in a few patches, - posting patches as attachments? The diffstat for the second attachment is: /PropertiesTableAttributesDxe/PropertiesTableAttributesDxe.uni |1 /PropertiesTableAttributesDxe/PropertiesTableAttributesDxeExtra.uni |1 Core/Dxe/DxeMain.h | 29 Core/Dxe/DxeMain.inf |4 Core/Dxe/DxeMain/DxeMain.c |2 Core/Dxe/Image/Image.c |2 Core/Dxe/Misc/PropertiesTable.c | 1418 ++ MdeModulePkg.dec | 22 MdeModulePkg.dsc |2 Universal/PropertiesTableAttributesDxe/PropertiesTableAttributesDxe.c | 412 ++ Universal/PropertiesTableAttributesDxe/PropertiesTableAttributesDxe.inf | 114 Universal/PropertiesTableAttributesDxe/PropertiesTableAttributesDxe.uni |1 Universal/PropertiesTableAttributesDxe/PropertiesTableAttributesDxeExtra.uni |1 13 files changed, 2009 insertions(+) Also, the longest line in the patch is 214 characters. Do you ever intend to adopt inline patches, to break up features into series of patches, and to follow the line length hints of the edk2 coding style? Honestly, I have the impression about these postings that they are an after-the-fact (non-)courtesy to the mailing list. We wrote this at Intel, it has been reviewed, it's going in, we'll ignore your formatting requests that you've repeated many times; if you are unable to review it as-is, your loss. If you are committed to ignore these bugs in your patches in the long term, I'd like to know that. Jiewen, it seems like Laszlo expressed some (valid) concerns with your patch, but you didn't respond, and checked them in anyway. Considering how much effort it is for people to code review patches, it is not very friendly to ignore their feedback. Occasionally, in urgent cases, we can disagree and still move forward even when there is disagreement, but I don't think it is good to ignore the discussion entirely and move forward with no regard for the concerns. Did you intend this edk2-devel code-review to actually be We wrote this at Intel, it has been reviewed, it's going in as was Laszlo's concern? I think the real start of the issue is that this should have been posted to edk2-devel before there was any Reviewed-by. And, following the posting, all feedback from the community should be considered. Mike, do you have any thoughts on how we might be able to address these issues? Maybe we could consider removing commit privileges for developers that don't follow the process? Is there someone else on the team besides you that I should ask this question to? Thanks, -Jordan -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v3 4/8] BaseTools/UniClassObject: Verify valid UCS-2 chars in UTF-16 .uni files
On 2015-06-07 20:44:16, Kinney, Michael D wrote: + +TheUcs2Codec = Ucs2Codec() This is creating a global object in this module for the USC-2 codec. Needs a comment to describe this. Ok. How about: ## Instance of Ucs2Codec class # # This object is used to support a codec for UCS-2 encoding # # The Ucs2Search function uses this object when a search for the usc-2 # codec is requested. # +# +# We currently only support UTF-16 +# +Encoding = 'utf-16' This comment is confusing because the patch allows UNI files to be in different encodings. Is this really referring to the encoding used internally to manage content read from an external file? In two patches later, BaseTools/UniClassObject: Support UTF-8 string data in .uni files (patch 6/8 for v3 and 06/10 for v4), I update this comment to: Detect Byte Order Mark at beginning of file. Default to UTF-8 That is the patch where we start to accept more than just UTF-16 input files. With the comment above added, and this explaination, do you think the patch is good enough to add your Reviewed-by signature? How about the other patches in the series? Thanks for your time, -Jordan -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH 00/21] OvmfPkg: support extra PCI root buses
On 2015-06-05 16:47:40, Laszlo Ersek wrote:
The first 9 patches are uninteresting (although they certainly decimated
my grey matter):
- Patch #1 copies PciHostBridgeDxe from PcAtChipsetPkg to OvmfPkg.
Arg. After I have bugged the DuetPkg and CorebootPayloadPkg package
owners to try to fixup PcAtChipsetPkg/PciHostBridgeDxe so all 3
platforms could potentially use it...
As far as I know, no one else is using PcAtChipsetPkg/PciHostBridgeDxe
right now, so if OVMF stops, then, I think, the attempt to make a
common driver in PcAtChipsetPkg has become a failure, and it should be
deleted. That will leave CorebootPayloadPkg still using the DuetPkg
one, and no path to resolve that odd situation.
So, what of this is OVMF specific?
Aside from fw-cfg patch, I think the method scanning for other
root-bridges in OvmfPkg: PciHostBridgeDxe: look for all root buses
might be OVMF specific. Looking for devices on other buses seems like
a platform specific way of doing that. (However, possibly something
configurable by PCD.)
What are the additional root bridges used for?
-Jordan
I
paid attention and passed the --find-copies-harder option to
git-format-patch, hence reviewers should be able to spot the minimal
differences easily.
- Patches #2 to #9 reformat the copied driver's source code so that it
is actually possible to work with it. Trailing whitespace is stripped,
overlong lines are rewrapped to 79 characters. This was suprisingly
difficult because the original code consistently uses 130-148 columns.
Rather than dump the reformatting into one huge patch, I broke it up
in order to help reviewers, generally keeping comment reformatting
separate from code reformatting. These patches are responsible for the
bulk of the diffstat.
This half of the series would actually apply to
PcAtChipsetPkg/PciHostBridgeDxe itself, and it would be possible to
clone the driver for OvmfPkg only at the end of the first half.
The other half of the series is more interesting:
- Patches #10 to #12 tweak PlatformBdsLib in preparation for multiple
root buses. For these:
Cc: Gabriel Somlo so...@cmu.edu
- Patches #13 to #19 clean up the cloned PciHostBridgeDxe, eliminating
the nominal (never used) multi-host-bridge bits, and fixing bugs in
the (until now unused, but soon to be exercised) multi-root-bridge
bits. At the end of this subset, single host bridge will be a
hard-coded trait, and several root bridges will be an actual
possibility.
- Patch #20 detects the extra root buses with a brute-force scan,
creating root bridge protocol instances in turn. The feature is
functionally complete after this patch.
- Patch #21 constrains the search based on fw_cfg, omitting it if QEMU
doesn't expose the number of extra root buses in fw_cfg, and
terminating the search ASAP otherwise.
Public branch:
https://github.com/lersek/edk2/commits/multiple_root_bridges_bz1193080
Laszlo Ersek (21):
OvmfPkg: clone PciHostBridgeDxe from PcAtChipsetPkg
OvmfPkg: PciHostBridgeDxe: rewrap IoFifo source files to 79 columns
OvmfPkg: PciHostBridgeDxe: rewrap INF file to 79 columns
OvmfPkg/PciHostBridgeDxe/PciHostBridge.h: rewrap comments to 79
columns
OvmfPkg/PciHostBridgeDxe/PciHostBridge.h: strip trailing ws from code
OvmfPkg/PciHostBridgeDxe/PciHostBridge.c: rewrap leading comments
OvmfPkg/PciHostBridgeDxe/PciHostBridge.c: rewrap code, strip trailing
ws
OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c: rewrap leading comments
OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c: rewrap code, strip
trailing ws
OvmfPkg: PlatformBdsLib: debug log interrupt line assignments
OvmfPkg: PlatformBdsLib: refine PCI host bridge assertion
OvmfPkg: PlatformBdsLib: connect all PCI root buses
OvmfPkg: PciHostBridgeDxe: eliminate nominal support for multiple host
bridges
OvmfPkg: PciHostBridgeDxe: kill RootBridgeNumber and
RootBridgeAttribute
OvmfPkg: PciHostBridgeDxe: embed device path in private root bridge
struct
OvmfPkg: PciHostBridgeDxe: factor out InitRootBridge() function
OvmfPkg: PciHostBridgeDxe: release resources on driver entry failure
OvmfPkg: PciHostBridgeDxe: use private buffer in
RootBridgeIoConfiguration()
OvmfPkg: PciHostBridgeDxe: eliminate
PCI_HOST_BRIDGE_INSTANCE.RootBridgeNumber
OvmfPkg: PciHostBridgeDxe: look for all root buses
OvmfPkg: PciHostBridgeDxe: shorten search for extra root buses
OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf |2 +-
{PcAtChipsetPkg = OvmfPkg}/PciHostBridgeDxe/PciHostBridgeDxe.inf | 21 +-
OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h | 25 +-
{PcAtChipsetPkg = OvmfPkg}/PciHostBridgeDxe/IoFifo.h | 11 +-
OvmfPkg/PciHostBridgeDxe/PciHostBridge.h | 651
+
OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c | 82 +-
Re: [edk2] [PATCH] OvmfPkg/PlatformPei: Initialise RCBA (B0:D31:F0 0xf0) register
On 2015-06-06 12:10:03, Paulo Alcantara wrote: This patch initialises root complex register block BAR in order to support TCO watchdog emulation features (e.g. reboot upon NO_REBOOT bit not set) on QEMU. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paulo Alcantara pca...@zytor.com --- OvmfPkg/Include/IndustryStandard/Q35MchIch9.h | 6 ++ OvmfPkg/OvmfPkg.dec | 4 OvmfPkg/PlatformPei/Platform.c| 7 +++ OvmfPkg/PlatformPei/PlatformPei.inf | 1 + 4 files changed, 18 insertions(+) diff --git a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h index 4f59a7c..4d42dfa 100644 --- a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h +++ b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h @@ -90,4 +90,10 @@ #define ICH9_SMI_EN_APMC_EN BIT5 #define ICH9_SMI_EN_GBL_SMI_EN BIT0 +// +// Root Complex Base Address register +// +#define ICH9_RCBA 0xf0 +#define ICH9_RCBA_EN BIT0 + #endif diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec index 4cb70dc..a6586f3 100644 --- a/OvmfPkg/OvmfPkg.dec +++ b/OvmfPkg/OvmfPkg.dec @@ -78,6 +78,10 @@ # to PIIX4 function 3 offset 0x40-0x43 bits [15:6]. gUefiOvmfPkgTokenSpaceGuid.PcdAcpiPmBaseAddress|0xB000|UINT16|5 + ## This flag determines the Root Complex Register Block BAR, written to Q35 + # function 31 offset 0xf0-0xf3 bits [31:14] + gUefiOvmfPkgTokenSpaceGuid.PcdRootComplexBaseAddress|0xfed1c000|UINT32|0x1e + ## When VirtioScsiDxe is instantiated for a HBA, the numbers of targets and # LUNs are retrieved from the host during virtio-scsi setup. # MdeModulePkg/Bus/Scsi/ScsiBusDxe then scans all MaxTarget * MaxLun diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c index 1126c65..09c9a2c 100644 --- a/OvmfPkg/PlatformPei/Platform.c +++ b/OvmfPkg/PlatformPei/Platform.c @@ -261,6 +261,13 @@ MiscInitialization ( Pmba = POWER_MGMT_REGISTER_Q35 (ICH9_PMBASE); AcpiCtlReg = POWER_MGMT_REGISTER_Q35 (ICH9_ACPI_CNTL); AcpiEnBit = ICH9_ACPI_CNTL_ACPI_EN; + + // + // Set Root Complex Register Block BAR + // + PciWrite32 (POWER_MGMT_REGISTER_Q35 (ICH9_RCBA), + PcdGet32 (PcdRootComplexBaseAddress) | (UINT32)ICH9_RCBA_EN Do we need a PCD here? How about just defining ICH9_ROOT_COMPLEX_BASE? -Jordan + ); break; default: DEBUG ((EFI_D_ERROR, %a: Unknown Host Bridge Device ID: 0x%04x\n, diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf b/OvmfPkg/PlatformPei/PlatformPei.inf index 0307bca..4aa47cc 100644 --- a/OvmfPkg/PlatformPei/PlatformPei.inf +++ b/OvmfPkg/PlatformPei/PlatformPei.inf @@ -74,6 +74,7 @@ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId + gUefiOvmfPkgTokenSpaceGuid.PcdRootComplexBaseAddress gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize -- 2.1.0 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [RFC 1/4] Add LinuxTerm terminal type to TerminalDxe
On 2015-05-13 16:53:58, Roy Franz wrote:
This patch adds new terminal type, LinuxTerm, to TerminalDxe. This terminal
type provides a place to add support for various Linux terminals that don't
behave like standard VT terminals.
Signed-off-by: Roy Franz roy.fr...@linaro.org
Contributed-under: TianoCore Contribution Agreement 1.0
---
BaseTools/Source/C/Include/Guid/PcAnsi.h | 6 +++
I think it best to avoid modifying multiple packages in a single
commit.
For one thing, you should provide a subject prefix, and usually this
should include the package being updated.
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
Yet, I think updating all PcAnsi.h files in a separate, single commit
might be okay here. (Although, it seems like only the MdePkg one is
used by this patch, and even that looks like it will need to move
since it is not in the spec. So, maybe no PcAnsi.h files will be
modified now?)
-Jordan
.../Foundation/Efi/Guid/PcAnsi/PcAnsi.c| 2 +
.../Foundation/Efi/Guid/PcAnsi/PcAnsi.h| 6 +++
.../Universal/BdsDxe/BootMaint/BootMaint.h | 2 +-
.../Universal/BdsDxe/BootMaint/Data.c | 5 ++-
.../Universal/Console/TerminalDxe/Terminal.c | 44
++
.../Universal/Console/TerminalDxe/Terminal.h | 1 +
.../Universal/Console/TerminalDxe/TerminalConIn.c | 4 +-
.../Universal/Console/TerminalDxe/TerminalConOut.c | 2 +
.../Universal/Console/TerminalDxe/TerminalDxe.inf | 1 +
MdePkg/Include/Guid/PcAnsi.h | 6 +++
MdePkg/Include/Protocol/DevicePath.h | 1 +
.../Library/UefiDevicePathLib/DevicePathFromText.c | 27 +
.../Library/UefiDevicePathLib/DevicePathToText.c | 3 ++
.../UefiDevicePathLib/UefiDevicePathLib.inf| 2 +
...UefiDevicePathLibOptionalDevicePathProtocol.inf | 4 +-
MdePkg/MdePkg.dec | 3 ++
.../UefiHandleParsingLib/UefiHandleParsingLib.c| 1 +
.../UefiHandleParsingLib/UefiHandleParsingLib.inf | 1 +
19 files changed, 109 insertions(+), 12 deletions(-)
diff --git a/BaseTools/Source/C/Include/Guid/PcAnsi.h
b/BaseTools/Source/C/Include/Guid/PcAnsi.h
index 9f12ca2..188a9b1 100644
--- a/BaseTools/Source/C/Include/Guid/PcAnsi.h
+++ b/BaseTools/Source/C/Include/Guid/PcAnsi.h
@@ -38,6 +38,11 @@
0xad15a0d6, 0x8bec, 0x4acf, {0xa0, 0x73, 0xd0, 0x1d, 0xe7, 0x7e, 0x2d,
0x88 } \
}
+#define EFI_LINUX_TERM_GUID \
+ { \
+0x7d916d80, 0x5bb1, 0x458c, {0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef,
0x94 } \
+ }
+
#define EFI_UART_DEVICE_PATH_GUID \
{ \
0x37499a9d, 0x542f, 0x4c89, {0xa0, 0x26, 0x35, 0xda, 0x14, 0x20, 0x94,
0xe4 } \
@@ -52,6 +57,7 @@ extern EFI_GUID gEfiPcAnsiGuid;
extern EFI_GUID gEfiVT100Guid;
extern EFI_GUID gEfiVT100PlusGuid;
extern EFI_GUID gEfiVTUTF8Guid;
+extern EFI_GUID gEfiLinuxTermGuid;
extern EFI_GUID gEfiUartDevicePathGuid;
extern EFI_GUID gEfiSasDevicePathGuid;
diff --git a/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.c
b/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.c
index 1f184e6..c6852b1 100644
--- a/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.c
+++ b/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.c
@@ -27,8 +27,10 @@ EFI_GUID gEfiPcAnsiGuid= EFI_PC_ANSI_GUID;
EFI_GUID gEfiVT100Guid = EFI_VT_100_GUID;
EFI_GUID gEfiVT100PlusGuid = EFI_VT_100_PLUS_GUID;
EFI_GUID gEfiVTUTF8Guid= EFI_VT_UTF8_GUID;
+EFI_GUID gEfiLinuxTermGuid = EFI_LINUX_TERM_GUID;
EFI_GUID_STRING(gEfiPcAnsiGuid, Efi, Efi PC ANSI Device Path Vendor
GUID)
EFI_GUID_STRING(gEfiVT100Guid, Efi, Efi VT100 Device Path Vendor GUID)
EFI_GUID_STRING(gEfiVT100PlusGuid, Efi, Efi VT100Plus Device Path Vendor
GUID)
EFI_GUID_STRING(gEfiVTUTF8Guid, Efi, Efi VTUTF8 Device Path Vendor GUID)
+EFI_GUID_STRING(gEfiLinuxTermGuid, Efi, Efi Linux Terminal Device Path
Vendor GUID)
diff --git a/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.h
b/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.h
index 7181020..9461a35 100644
--- a/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.h
+++ b/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.h
@@ -42,9 +42,15 @@ Abstract:
0xad15a0d6, 0x8bec, 0x4acf, {0xa0, 0x73, 0xd0, 0x1d, 0xe7, 0x7e, 0x2d,
0x88} \
}
+#define EFI_LINUX_TERM_GUID \
+ { \
+0x7d916d80, 0x5bb1, 0x458c, {0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef,
0x94 } \
+ }
+
extern EFI_GUID gEfiPcAnsiGuid;
extern EFI_GUID gEfiVT100Guid;
extern EFI_GUID gEfiVT100PlusGuid;
extern EFI_GUID gEfiVTUTF8Guid;
+extern EFI_GUID gEfiLinuxTermGuid;
#endif
diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/BootMaint.h
b/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/BootMaint.h
index 098692f..bfa9b63 100644
--- a/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/BootMaint.h
+++
[edk2] [PATCH v4 05/10] BaseTools/Tests: Verify unsupported UTF-16 are rejected
Supplementary Plane characters can exist in UTF-16 files,
but they are not valid UCS-2 characters.
For example, this python interpreter code:
import codecs
codecs.encode(u'\U00010300', 'utf-16')
'\xff\xfe\x00\xd8\x00\xdf'
Therefore the UCS-4 0x00010300 character is encoded as two
16-bit numbers (0xd800 0xdf00) in a little endian UTF-16
file.
For more information, see:
http://en.wikipedia.org/wiki/UTF-16#U.2B1_to_U.2B10
This test checks to make sure that BaseTools will reject these
characters in UTF-16 files.
The range of 0xd800 - 0xdfff should also be rejected as unicode code
points because they are reserved for the surrogate pair usage in
UTF-16 files.
This test was fixed by the previous commit:
BaseTools/UniClassObject: Verify valid UCS-2 chars in UTF-16 .uni files
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: Yingke D Liu yingke.d@intel.com
Cc: Michael D Kinney michael.d.kin...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
---
BaseTools/Tests/CheckUnicodeSourceFiles.py | 35 +-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/BaseTools/Tests/CheckUnicodeSourceFiles.py
b/BaseTools/Tests/CheckUnicodeSourceFiles.py
index 0083ad8..ad5fd18 100644
--- a/BaseTools/Tests/CheckUnicodeSourceFiles.py
+++ b/BaseTools/Tests/CheckUnicodeSourceFiles.py
@@ -38,7 +38,10 @@ class Tests(TestTools.BaseToolsTest):
def EncodeToFile(self, encoding, string=None):
if string is None:
string = self.SampleData
-data = codecs.encode(string, encoding)
+if encoding is not None:
+data = codecs.encode(string, encoding)
+else:
+data = string
path = 'input.uni'
self.WriteTmpFile(path, data)
return PathClass(self.GetTmpFilePath(path))
@@ -81,6 +84,36 @@ class Tests(TestTools.BaseToolsTest):
def testUtf16InUniFile(self):
self.CheckFile('utf_16', shouldPass=True)
+def testSupplementaryPlaneUnicodeCharInUtf16File(self):
+#
+# Supplementary Plane characters can exist in UTF-16 files,
+# but they are not valid UCS-2 characters.
+#
+# This test makes sure that BaseTools rejects these characters
+# if seen in a .uni file.
+#
+data = u'''
+#langdef en-US English
+#string STR_A #language en-US CodePoint (\U00010300) 0x
+'''
+
+self.CheckFile('utf_16', shouldPass=False, string=data)
+
+def testSurrogatePairUnicodeCharInUtf16File(self):
+#
+# Surrogate Pair code points are used in UTF-16 files to
+# encode the Supplementary Plane characters. But, a Surrogate
+# Pair code point which is not followed by another Surrogate
+# Pair code point might be interpreted as a single code point
+# with the Surrogate Pair code point.
+#
+# This test makes sure that BaseTools rejects these characters
+# if seen in a .uni file.
+#
+data = codecs.BOM_UTF16_LE + '//\x01\xd8 '
+
+self.CheckFile(encoding=None, shouldPass=False, string=data)
+
TheTestSuite = TestTools.MakeTheTestSuite(locals())
if __name__ == '__main__':
--
2.1.4
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v4 00/10] Support UTF-8 in .uni string files
https://github.com/jljusten/edk2.git utf8-v4 v4: * Reject characters in the range 0xd800 - 0xdfff since they are reserved for UTF-16 Surrogate Pairs. (lersek) * Add more tests to verify the Surrogate Pairs range is rejected, and that UTF-8 BOM is allowed. (lersek) v3: * v2 fixed the USC-2 issue with UTF-16 file by 'accident'. Now this is done in separate patches. (Patches 3 4) * Validate entire file by loading the entire contents (mdkinney) * Add stub version of ucs-2 codec to verify unicode file contents are valid USC-2 characters. v2: * Drop .utf8 extension. Use .uni file for UTF-8 data (mdkinney) The UTF-16 .uni files are fairly annoying to work with: * They must be checked in as 'binary' files * It is difficult to produce a diff of changes * UTF-8 is more likely to be supported by text editors This series allows .uni files to contain UTF-8 (or, as before, UTF-16) string data. If the UTF-16 LE or BE BOM is found, then the file is read as UTF-16. Otherwise, it is treated as UTF-8. Jordan Justen (10): BaseTools/Tests: Always add BaseTools source to import path BaseTools/EdkLogger: Support unit tests with a SILENT log level BaseTools/Tests: Add unit test for AutoGen.UniClassObject BaseTools/UniClassObject: Verify valid UCS-2 chars in UTF-16 .uni files BaseTools/Tests: Verify unsupported UTF-16 are rejected BaseTools/UniClassObject: Support UTF-8 string data in .uni files BaseTools/Tests: Verify 32-bit UTF-8 chars are rejected BaseTools/Tests: Verify unsupported UTF-8 data is rejected BaseTools/Tests: Verify supported UTF-8 data is allowed OvmfPkg/PlatformDxe: Convert Platform.uni to UTF-8 BaseTools/Source/Python/AutoGen/UniClassObject.py | 91 ++- BaseTools/Source/Python/Common/EdkLogger.py | 9 +- BaseTools/Tests/CheckUnicodeSourceFiles.py| 181 ++ BaseTools/Tests/PythonToolsTests.py | 4 +- BaseTools/Tests/RunTests.py | 2 - BaseTools/Tests/TestTools.py | 9 +- OvmfPkg/PlatformDxe/Platform.uni | Bin 3298 - 1648 bytes 7 files changed, 289 insertions(+), 7 deletions(-) create mode 100644 BaseTools/Tests/CheckUnicodeSourceFiles.py -- 2.1.4 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v4 03/10] BaseTools/Tests: Add unit test for AutoGen.UniClassObject
This verifies that a UTF-16 data (with BOM) .uni file is successfully
read.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: Yingke D Liu yingke.d@intel.com
---
BaseTools/Tests/CheckUnicodeSourceFiles.py | 88 ++
BaseTools/Tests/PythonToolsTests.py| 4 +-
2 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 BaseTools/Tests/CheckUnicodeSourceFiles.py
diff --git a/BaseTools/Tests/CheckUnicodeSourceFiles.py
b/BaseTools/Tests/CheckUnicodeSourceFiles.py
new file mode 100644
index 000..0083ad8
--- /dev/null
+++ b/BaseTools/Tests/CheckUnicodeSourceFiles.py
@@ -0,0 +1,88 @@
+## @file
+# Unit tests for AutoGen.UniClassObject
+#
+# Copyright (c) 2015, Intel Corporation. All rights reserved.BR
+#
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD
License
+# which accompanies this distribution. The full text of the license may be
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+#
+
+##
+# Import Modules
+#
+import os
+import unittest
+
+import codecs
+
+import TestTools
+
+from Common.Misc import PathClass
+import AutoGen.UniClassObject as BtUni
+
+from Common import EdkLogger
+EdkLogger.InitializeForUnitTest()
+
+class Tests(TestTools.BaseToolsTest):
+
+SampleData = u'''
+#langdef en-US English
+#string STR_A #language en-US STR_A for en-US
+'''
+
+def EncodeToFile(self, encoding, string=None):
+if string is None:
+string = self.SampleData
+data = codecs.encode(string, encoding)
+path = 'input.uni'
+self.WriteTmpFile(path, data)
+return PathClass(self.GetTmpFilePath(path))
+
+def ErrorFailure(self, error, encoding, shouldPass):
+msg = error + ' should '
+if shouldPass:
+msg += 'not '
+msg += 'be generated for '
+msg += '%s data in a .uni file' % encoding
+self.fail(msg)
+
+def UnicodeErrorFailure(self, encoding, shouldPass):
+self.ErrorFailure('UnicodeError', encoding, shouldPass)
+
+def EdkErrorFailure(self, encoding, shouldPass):
+self.ErrorFailure('EdkLogger.FatalError', encoding, shouldPass)
+
+def CheckFile(self, encoding, shouldPass, string=None):
+path = self.EncodeToFile(encoding, string)
+try:
+BtUni.UniFileClassObject([path])
+if shouldPass:
+return
+except UnicodeError:
+if not shouldPass:
+return
+else:
+self.UnicodeErrorFailure(encoding, shouldPass)
+except EdkLogger.FatalError:
+if not shouldPass:
+return
+else:
+self.EdkErrorFailure(encoding, shouldPass)
+except Exception:
+pass
+
+self.EdkErrorFailure(encoding, shouldPass)
+
+def testUtf16InUniFile(self):
+self.CheckFile('utf_16', shouldPass=True)
+
+TheTestSuite = TestTools.MakeTheTestSuite(locals())
+
+if __name__ == '__main__':
+allTests = TheTestSuite()
+unittest.TextTestRunner().run(allTests)
diff --git a/BaseTools/Tests/PythonToolsTests.py
b/BaseTools/Tests/PythonToolsTests.py
index 6096e21..c953daf 100644
--- a/BaseTools/Tests/PythonToolsTests.py
+++ b/BaseTools/Tests/PythonToolsTests.py
@@ -1,7 +1,7 @@
## @file
# Unit tests for Python based BaseTools
#
-# Copyright (c) 2008, Intel Corporation. All rights reserved.BR
+# Copyright (c) 2008 - 2015, Intel Corporation. All rights reserved.BR
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD
License
@@ -24,6 +24,8 @@ def TheTestSuite():
suites = []
import CheckPythonSyntax
suites.append(CheckPythonSyntax.TheTestSuite())
+import CheckUnicodeSourceFiles
+suites.append(CheckUnicodeSourceFiles.TheTestSuite())
return unittest.TestSuite(suites)
if __name__ == '__main__':
--
2.1.4
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v4 06/10] BaseTools/UniClassObject: Support UTF-8 string data in .uni files
This allows .uni input files to be encoded with UTF-8. Today, we only support UTF-16 encoding. The strings are still converted to UCS-2 data for use in EDK II modules. (This is the only unicode character format supported by UEFI and EDK II.) Although UTF-8 would allow any UCS-4 character to be present in the source file, we restrict the entire file to the UCS-2 range. (Including comments.) This allows the files to be converted to UTF-16 if needed. v2: * Drop .utf8 extension. Use .uni file for UTF-8 data (mdkinney) * Merge in 'BaseTools/UniClassObject: Verify string data is 16-bit' commit v3: * Restrict the entire file's characters (including comments) to the UCS-2 range in addition to string data. (mdkinney) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Cc: Yingke D Liu yingke.d@intel.com Cc: Michael D Kinney michael.d.kin...@intel.com --- BaseTools/Source/Python/AutoGen/UniClassObject.py | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/BaseTools/Source/Python/AutoGen/UniClassObject.py b/BaseTools/Source/Python/AutoGen/UniClassObject.py index 386e1ec..1578205 100644 --- a/BaseTools/Source/Python/AutoGen/UniClassObject.py +++ b/BaseTools/Source/Python/AutoGen/UniClassObject.py @@ -297,9 +297,12 @@ class UniFileClassObject(object): EdkLogger.Error(build, FILE_OPEN_FAILURE, ExtraData=File) # -# We currently only support UTF-16 +# Detect Byte Order Mark at beginning of file. Default to UTF-8 # -Encoding = 'utf-16' +Encoding = 'utf-8' +if (FileIn.startswith(codecs.BOM_UTF16_BE) or +FileIn.startswith(codecs.BOM_UTF16_LE)): +Encoding = 'utf-16' self.VerifyUcs2Data(FileIn, FileName, Encoding) -- 2.1.4 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v4 07/10] BaseTools/Tests: Verify 32-bit UTF-8 chars are rejected
Since UTF-8 .uni unicode files might contain strings with unicode code
points larger than 16-bits, and UEFI only supports UCS-2 characters,
we need to make sure that BaseTools rejects these characters in UTF-8
.uni source files.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: Yingke D Liu yingke.d@intel.com
---
BaseTools/Tests/CheckUnicodeSourceFiles.py | 25 +
1 file changed, 25 insertions(+)
diff --git a/BaseTools/Tests/CheckUnicodeSourceFiles.py
b/BaseTools/Tests/CheckUnicodeSourceFiles.py
index ad5fd18..102dc3c 100644
--- a/BaseTools/Tests/CheckUnicodeSourceFiles.py
+++ b/BaseTools/Tests/CheckUnicodeSourceFiles.py
@@ -114,6 +114,31 @@ class Tests(TestTools.BaseToolsTest):
self.CheckFile(encoding=None, shouldPass=False, string=data)
+def test32bitUnicodeCharInUtf8File(self):
+data = u'''
+#langdef en-US English
+#string STR_A #language en-US CodePoint (\U00010300) 0x
+'''
+
+self.CheckFile('utf_16', shouldPass=False, string=data)
+
+def test32bitUnicodeCharInUtf8File(self):
+data = u'''
+#langdef en-US English
+#string STR_A #language en-US CodePoint (\U00010300) 0x
+'''
+
+self.CheckFile('utf_8', shouldPass=False, string=data)
+
+def test32bitUnicodeCharInUtf8Comment(self):
+data = u'''
+// Even in comments, we reject non-UCS-2 chars: \U00010300
+#langdef en-US English
+#string STR_A #language en-US A
+'''
+
+self.CheckFile('utf_8', shouldPass=False, string=data)
+
TheTestSuite = TestTools.MakeTheTestSuite(locals())
if __name__ == '__main__':
--
2.1.4
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v4 04/10] BaseTools/UniClassObject: Verify valid UCS-2 chars in UTF-16 .uni files
Supplementary Plane characters can exist in UTF-16 files,
but they are not valid UCS-2 characters.
For example, refer to this python interpreter code:
import codecs
codecs.encode(u'\U00010300', 'utf-16')
'\xff\xfe\x00\xd8\x00\xdf'
Therefore the UCS-4 0x00010300 character is encoded as two
16-bit numbers (0xd800 0xdf00) in a little endian UTF-16
file.
For more information, see:
http://en.wikipedia.org/wiki/UTF-16#U.2B1_to_U.2B10
This means that our current BaseTools code could be allowing
unsupported UTF-16 characters be used. To fix this, we decode the file
using python's utf-16 decode support. Then we verify that each
character's code point is 0x or less.
v3:
* Based on Mike Kinney's feedback, we now read the whole file and
verify up-front that it contains valid UCS-2 characters. Thanks
also to Laszlo Ersek for pointing out the Supplementary Plane
characters.
v4:
* Reject code points in 0xd800-0xdfff range since they are reserved
for UTF-16 surrogate pairs. (lersek)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: Yingke D Liu yingke.d@intel.com
Cc: Michael D Kinney michael.d.kin...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
---
BaseTools/Source/Python/AutoGen/UniClassObject.py | 88 ++-
1 file changed, 86 insertions(+), 2 deletions(-)
diff --git a/BaseTools/Source/Python/AutoGen/UniClassObject.py
b/BaseTools/Source/Python/AutoGen/UniClassObject.py
index aa54f4f..386e1ec 100644
--- a/BaseTools/Source/Python/AutoGen/UniClassObject.py
+++ b/BaseTools/Source/Python/AutoGen/UniClassObject.py
@@ -19,6 +19,7 @@
import Common.LongFilePathOs as os, codecs, re
import distutils.util
import Common.EdkLogger as EdkLogger
+import StringIO
from Common.BuildToolError import *
from Common.String import GetLineNo
from Common.Misc import PathClass
@@ -147,6 +148,37 @@ def GetLanguageCode(LangName, IsCompatibleMode, File):
EdkLogger.error(Unicode File Parser, FORMAT_INVALID, Invalid RFC 4646
language code : %s % LangName, File)
+## Ucs2Codec
+#
+# This is only a partial codec implementation. It only supports
+# encoding, and is primarily used to check that all the characters are
+# valid for UCS-2.
+#
+class Ucs2Codec(codecs.Codec):
+def __init__(self):
+self.__utf16 = codecs.lookup('utf-16')
+
+def encode(self, input, errors='strict'):
+for Char in input:
+CodePoint = ord(Char)
+if CodePoint = 0xd800 and CodePoint = 0xdfff:
+raise ValueError(Code Point is in range reserved for +
+ UTF-16 surrogate pairs)
+elif CodePoint 0x:
+raise ValueError(Code Point too large to encode in UCS-2)
+return self.__utf16.encode(input)
+
+TheUcs2Codec = Ucs2Codec()
+def Ucs2Search(name):
+if name == 'ucs-2':
+return codecs.CodecInfo(
+name=name,
+encode=TheUcs2Codec.encode,
+decode=TheUcs2Codec.decode)
+else:
+return None
+codecs.register(Ucs2Search)
+
## StringDefClassObject
#
# A structure for language definition
@@ -209,7 +241,7 @@ class UniFileClassObject(object):
Lang = distutils.util.split_quoted((Line.split(u//)[0]))
if len(Lang) != 3:
try:
-FileIn = codecs.open(LongFilePath(File.Path), mode='rb',
encoding='utf-16').read()
+FileIn = self.OpenUniFile(LongFilePath(File.Path))
except UnicodeError, X:
EdkLogger.error(build, FILE_READ_FAILURE, File read
failure: %s % str(X), ExtraData=File);
except:
@@ -253,6 +285,58 @@ class UniFileClassObject(object):
self.OrderedStringDict[LangName][Item.StringName] =
len(self.OrderedStringList[LangName]) - 1
return True
+def OpenUniFile(self, FileName):
+#
+# Read file
+#
+try:
+UniFile = open(FileName, mode='rb')
+FileIn = UniFile.read()
+UniFile.close()
+except:
+EdkLogger.Error(build, FILE_OPEN_FAILURE, ExtraData=File)
+
+#
+# We currently only support UTF-16
+#
+Encoding = 'utf-16'
+
+self.VerifyUcs2Data(FileIn, FileName, Encoding)
+
+UniFile = StringIO.StringIO(FileIn)
+Info = codecs.lookup(Encoding)
+(Reader, Writer) = (Info.streamreader, Info.streamwriter)
+return codecs.StreamReaderWriter(UniFile, Reader, Writer)
+
+def VerifyUcs2Data(self, FileIn, FileName, Encoding):
+Ucs2Info = codecs.lookup('ucs-2')
+#
+# Convert to unicode
+#
+try:
+FileDecoded = codecs.decode(FileIn, Encoding)
+Ucs2Info.encode(FileDecoded)
+except:
+UniFile = StringIO.StringIO(FileIn)
+Info = codecs.lookup(Encoding)
+(Reader, Writer) = (Info.streamreader, Info.streamwriter
[edk2] [PATCH v4 02/10] BaseTools/EdkLogger: Support unit tests with a SILENT log level
This allows the unit tests to run without the errors logging to the screen. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Cc: Yingke D Liu yingke.d@intel.com --- BaseTools/Source/Python/Common/EdkLogger.py | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/BaseTools/Source/Python/Common/EdkLogger.py b/BaseTools/Source/Python/Common/EdkLogger.py index f048b61..8d6d426 100644 --- a/BaseTools/Source/Python/Common/EdkLogger.py +++ b/BaseTools/Source/Python/Common/EdkLogger.py @@ -32,6 +32,7 @@ INFO= 20 WARN= 30 QUIET = 40 ERROR = 50 +SILENT = 99 IsRaiseError = True @@ -39,7 +40,9 @@ IsRaiseError = True _ToolName = os.path.basename(sys.argv[0]) # For validation purpose -_LogLevels = [DEBUG_0, DEBUG_1, DEBUG_2, DEBUG_3, DEBUG_4, DEBUG_5, DEBUG_6, DEBUG_7, DEBUG_8, DEBUG_9, VERBOSE, WARN, INFO, ERROR, QUIET] +_LogLevels = [DEBUG_0, DEBUG_1, DEBUG_2, DEBUG_3, DEBUG_4, DEBUG_5, + DEBUG_6, DEBUG_7, DEBUG_8, DEBUG_9, VERBOSE, WARN, INFO, + ERROR, QUIET, SILENT] # For DEBUG level (All DEBUG_0~9 are applicable) _DebugLogger = logging.getLogger(tool_debug) @@ -235,6 +238,10 @@ def SetLevel(Level): _InfoLogger.setLevel(Level) _ErrorLogger.setLevel(Level) +def InitializeForUnitTest(): +Initialize() +SetLevel(SILENT) + ## Get current log level def GetLevel(): return _InfoLogger.getEffectiveLevel() -- 2.1.4 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v4 09/10] BaseTools/Tests: Verify supported UTF-8 data is allowed
We test a simple case of UTF-8 with and without the UTF-8 BOM. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Cc: Yingke D Liu yingke.d@intel.com Cc: Michael D Kinney michael.d.kin...@intel.com Cc: Laszlo Ersek ler...@redhat.com --- BaseTools/Tests/CheckUnicodeSourceFiles.py | 11 +++ 1 file changed, 11 insertions(+) diff --git a/BaseTools/Tests/CheckUnicodeSourceFiles.py b/BaseTools/Tests/CheckUnicodeSourceFiles.py index 2eeb0f5..6ae62f1 100644 --- a/BaseTools/Tests/CheckUnicodeSourceFiles.py +++ b/BaseTools/Tests/CheckUnicodeSourceFiles.py @@ -114,6 +114,17 @@ class Tests(TestTools.BaseToolsTest): self.CheckFile(encoding=None, shouldPass=False, string=data) +def testValidUtf8File(self): +self.CheckFile(encoding='utf_8', shouldPass=True) + +def testValidUtf8FileWithBom(self): +# +# Same test as testValidUtf8File, but add the UTF-8 BOM +# +data = codecs.BOM_UTF8 + codecs.encode(self.SampleData, 'utf_8') + +self.CheckFile(encoding=None, shouldPass=True, string=data) + def test32bitUnicodeCharInUtf8File(self): data = u''' #langdef en-US English -- 2.1.4 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v4 01/10] BaseTools/Tests: Always add BaseTools source to import path
This allows unit tests to easily include BaseTools python modules. This is very useful for writing unit tests. Actually, previously, we would do this when RunTests.py was executed, so unit tests could easily import BaseTools modules, so long as they were executed via RunTests. This change allows running the unit test files individually which can be faster for developing the new unit test cases. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Cc: Yingke D Liu yingke.d@intel.com --- BaseTools/Tests/RunTests.py | 2 -- BaseTools/Tests/TestTools.py | 9 - 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/BaseTools/Tests/RunTests.py b/BaseTools/Tests/RunTests.py index e8ca2d0..0dd6563 100644 --- a/BaseTools/Tests/RunTests.py +++ b/BaseTools/Tests/RunTests.py @@ -21,8 +21,6 @@ import unittest import TestTools -sys.path.append(TestTools.PythonSourceDir) - def GetCTestSuite(): import CToolsTests return CToolsTests.TheTestSuite() diff --git a/BaseTools/Tests/TestTools.py b/BaseTools/Tests/TestTools.py index ac009db..27afd79 100644 --- a/BaseTools/Tests/TestTools.py +++ b/BaseTools/Tests/TestTools.py @@ -1,7 +1,7 @@ ## @file # Utility functions and classes for BaseTools unit tests # -# Copyright (c) 2008 - 2012, Intel Corporation. All rights reserved.BR +# Copyright (c) 2008 - 2015, Intel Corporation. All rights reserved.BR # # This program and the accompanying materials # are licensed and made available under the terms and conditions of the BSD License @@ -31,6 +31,13 @@ CSourceDir = os.path.join(BaseToolsDir, 'Source', 'C') PythonSourceDir = os.path.join(BaseToolsDir, 'Source', 'Python') TestTempDir = os.path.join(TestsDir, 'TestTempDir') +if PythonSourceDir not in sys.path: +# +# Allow unit tests to import BaseTools python modules. This is very useful +# for writing unit tests. +# +sys.path.append(PythonSourceDir) + def MakeTheTestSuite(localItems): tests = [] for name, item in localItems.iteritems(): -- 2.1.4 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v4 10/10] OvmfPkg/PlatformDxe: Convert Platform.uni to UTF-8
This command was used to convert the file:
iconv -f UTF-16 -t UTF-8 \
-o OvmfPkg/PlatformDxe/Platform.uni \
OvmfPkg/PlatformDxe/Platform.uni
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Laszlo Ersek ler...@redhat.com
---
OvmfPkg/PlatformDxe/Platform.uni | Bin 3298 - 1648 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/OvmfPkg/PlatformDxe/Platform.uni b/OvmfPkg/PlatformDxe/Platform.uni
index
d8d5b0bb4de9c0632dc183369fa7d46f455e9143..6df865519f35e302430f1ad290729011fd4c9048
100644
GIT binary patch
literal 1648
zcmai!QE$^Q5Xaw_ztJ-1=yAX;)My2($-@UYg#2KjHk*?E{UbYj%=sf`1G9JEUQh
zN!Wq?rV%zPrf;-khDid@-50FU(Z;phZ%cr|+s@87=ra1IF;aLwGL^2N!qjDGZ
z_M=0*igRil;0_89-H;9+d8q_;1f=|=r%eY%s3j{2mF6vQS%9q(c%G}aMKhs
z3R-Sa3*H#u8le$6N(s7Y|9G@-f_|JZGD{FALNjLRl^4P*|HA)Foqs`P8qbPhLr
z65Q1yug5I~8j29c!wO-n7TbP*mW-5@Jsrs6y?rDNdPvFxY-wGQ0N~cA*VcBIlZom`
zvFdefzs7v$S{+wDK3VGpsTw-mRvJfCCjf#xPT~yd6Z^JG+k$G4(oW%638gPpCFpC
zIAySmAlW9OeyXrePYT=U%{%D7#*+Gx!lENf7lOJSKn!d3}OS)7Ggw2bN16{Y`#
zZ5ry2SzEh1-o@IF5H8n#p)(vbARz#X=Q*gAnr;FGt}3tA^WB={D%47+;55a*^lu
z@4%FNrMoS#6mqy4${X{qh+%?VsYl4g#TzP5di;Fqeoh-ME6N6x7wZGn5-IMJz`_
zE{))1+vaMSEK-(jvM9S@FnoM+ntY)UVdL(jeAo8%TiSRzJ!T*`V8-y-K-vQaKxL{
zqz+-nwNSkQkM9O+z@W7xjbhPMHt0i@84pN(4LhJhyw!M*k-m)MqU2T5n-jVM6IcX
z5;Usu#Z46pv8(E-QucZ3=HEwlC!iyh(wR~aZi@2Js?bC=erZ7oQ*Cb;|AhOW
znL|C)Q-9N_pn_-N)U3#8SZk8fA_kDyc~PYq-;t=cdI@6sW*;ixI!@{k(k%x$M
zt{j;%+}N|;xWfFGIgb9sog?~B)kDrDm=1GMJ^-hq-wk8L%A*7QI1@yQDXqkTqu1
zG%HKd}4H1u;N0}yZ8|hTqwS-9}G5I1)KiZ7VG7o!Adfb}tUAfu_+cOy*BN36Lp
MIoHK=u$M11Ja-Rz5oCK
literal 3298
zcmb`J+fP$L5XR@(#Q)(0Uc3Qne37ULm!geA2`ws5OUU1q!-dtKXv?-#6Pmrx)l^
zVw#@4CYx~^Udu3{URWme@0UhN23VziaDiS60QF74LF*0Zi%*aX=p%s!=kZ7=PW
zy|EYcPpoa{w4bbjjAqIw3claS|@WUfSDi=LCIyw8;J#1o}#IkKPciiS4j1i5yw#
zqqe29ow}d+O7J3%U;(j(EnzYMiHsbb|gddb@68z_@`8oo0eW+s7@=GO_`ZTDxW6
z5cz}|p_08Gy}oN}Fw(9*b1iy9MjhwuXdeJHDA;3A=|Jf-*$#Gu`5R*-8qtAYcRDF
zPzsrPz05y4)5tnA`*y8r`;5QLVM^@AebC}7bn~a|fkv9-1^FrWoNT4c(otfc;Pv
z)#*FThX@Jt4`dcGHE?#@)oJ)bpL4T0U?{rSQiT?L}J^yDt-nZOMdJg-{kaT;L37
zgOrj$j@zKVPz977yRQHV=I?vJ$9{VNu0C^4+mR#$`O3;8V3VX3OyGlwQgGd}Fu
zCFXMtc?`%x`ag4HCO0~-$*O0Tr8(eCKqZb*r#J;gETot#d@eY=R?1=d?TBW1n
z)=wA-yXIuGhLmJvHAo#GtDR@GpIH%dWpHU~C7hyU-!nZ?d+wzJ~@V6vb{f(^|{0$
zF*$cmh#g17bU@s;vs2}g3G2tiM^W#1BnN0zHuUb0-tmZvi{kI(UX4}O#Mh9w%D#?|
z=CdZ)Teg2N#gTKnw{f2kZi!JXVdB#PV?T@T~4EQKas2l+ljMwg9yr-YxqrT%83*v
zuFdR=nHG=-w$x9p~)ty$e;S|bADijRae1(s?*j=;v9H8WJXrL5sK7(_RoC+?
zufhT2dR7Tm5L!WLH|59jf(N@;StrfL#?+kyO5??9b6(F0dwHy-nOzpR`-iTaEgV
zOi%{o{=Lt$#i(;!)ddu*F@#*LQzK42gO@!PXNoZ#0y+w}^VWg+Y^c(0HDVx7s
zR(Tm~^)3=4*8c@--D~ATqa1Gz-NuWUHM5L){*L|zJ}Lv-MeCjUJtr`byl%n+)bE?
zXKYT-sP{zK*9I^pzH`Doq`DJWq?)LEMcJd*#gLwOB|a)|=ZEI`|0H)d(t)ZJ@UNX
zOgHSGz{31SzxJJNq!gKOx1`MdL_-lBU6sZt?yKT$cyE+m?`r)_VJr74xCYiP-Pw
zPBHc~ym!UvTSP)pNQXG!iyc=YKnV^`VH+YyA;C^sd$R`;w$EoUO8f=Vi}nms${6
z-j%vx`oud(h8JKLG-8da`u|};71n%(0d;4AUIxqY4QG{RK^VW=~h(!aJm16yL8U
k-gA;zT^qvNXb*HJya`sJE5@~tz0~77_B{JLWV(0%07EhSy8r+H
--
2.1.4
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v4 08/10] BaseTools/Tests: Verify unsupported UTF-8 data is rejected
Surrogate pair characters can be encoded in UTF-8 files, but they are
not valid UCS-2 characters.
For example, this python interpreter code:
import codecs
codecs.encode(u'\ud801', 'utf-8')
'\xed\xa0\x81'
But, the range of 0xd800 - 0xdfff should be rejected as unicode code
points because they are reserved for the surrogate pair usage in
UTF-16 files.
We test that this case is rejected for UTF-8 with and without the
UTF-8 BOM.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: Yingke D Liu yingke.d@intel.com
Cc: Michael D Kinney michael.d.kin...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
---
BaseTools/Tests/CheckUnicodeSourceFiles.py | 24
1 file changed, 24 insertions(+)
diff --git a/BaseTools/Tests/CheckUnicodeSourceFiles.py
b/BaseTools/Tests/CheckUnicodeSourceFiles.py
index 102dc3c..2eeb0f5 100644
--- a/BaseTools/Tests/CheckUnicodeSourceFiles.py
+++ b/BaseTools/Tests/CheckUnicodeSourceFiles.py
@@ -139,6 +139,30 @@ class Tests(TestTools.BaseToolsTest):
self.CheckFile('utf_8', shouldPass=False, string=data)
+def testSurrogatePairUnicodeCharInUtf8File(self):
+#
+# Surrogate Pair code points are used in UTF-16 files to
+# encode the Supplementary Plane characters. In UTF-8, it is
+# trivial to encode these code points, but they are not valid
+# code points for characters, since they are reserved for the
+# UTF-16 Surrogate Pairs.
+#
+# This test makes sure that BaseTools rejects these characters
+# if seen in a .uni file.
+#
+data = '\xed\xa0\x81'
+
+self.CheckFile(encoding=None, shouldPass=False, string=data)
+
+def testSurrogatePairUnicodeCharInUtf8FileWithBom(self):
+#
+# Same test as testSurrogatePairUnicodeCharInUtf8File, but add
+# the UTF-8 BOM
+#
+data = codecs.BOM_UTF8 + '\xed\xa0\x81'
+
+self.CheckFile(encoding=None, shouldPass=False, string=data)
+
TheTestSuite = TestTools.MakeTheTestSuite(locals())
if __name__ == '__main__':
--
2.1.4
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] Proposal of Git Repo Layout for EDKII project
On 2015-06-03 12:01:58, Andrew Fish wrote: On Jun 3, 2015, at 7:50 AM, Brian J. Johnson bjohn...@sgi.com wrote: I fully agree with others' reluctance to use git submodules, and the reasons they have expressed: git submodules are a major pain for developers, and the concerns Liming listed above can be addressed in other ways. When my internal team first transitioned to git, we set up a complex submodule-like system to (theoretically) allow easily updating common code among different projects. That only lasted a month or two: having to manage multiple repositories for day-to-day work, and the lack of a single commit history spanning the entire tree doomed that scheme. I collapsed everything together into a single repo using some git filter-branch magic, and we've been happy ever since. Please, no submodules…. I agree that submodules add complexity, and make things harder. Maybe for hardware project they are OK, but the core of edk2 should be one project. I also would prefer if EDK II upstream could be a single repo, but I understand why there is also a desire to consider submodules. First and foremost, inside Intel, the svn:externals feature is used extensively to compose platform trees together. And, submodules map very closely to that usage model. But, even if you try to consider alternatives to submodules for composing platform trees, things get complicated. One idea, is to fork the EDK II master tree, and add submodules for your platform specific modules. To me this ends up with the worst of both worlds. 1. All git commands are difficult to use tree-wide, as expressed in this thread, and 2. You don't have the power to select only the EDK II modules that you need for your platform. Another idea is to fork the EDK II master tree and add your platform specific modules directly into the fork. In this case, you can still use all the git commands, but you once again can't select only the EDK II modules that you need for your platform. Other difficulties arise, such as, what if you have a chipset package that you want to share for multiple platforms? Unless all the platforms for that chipset live in the same branch, how do you easily share common code for those chipset packages? (Maybe a separate 'upstream' for the chipset code that the platforms merge in as needed?) I think Android might share some of the same concerns, and their solution was to invent a submodules-like alternative called 'repo' that layers on git. So, can we add these concerns into the discussion, and maybe document an alternative way to address these concerns if submodules aren't used? Thanks, -Jordan -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] Proposal of Git Repo Layout for EDKII project
On 2015-06-03 18:17:26, Andrew Fish wrote: On Jun 3, 2015, at 5:59 PM, Roy Franz roy.fr...@linaro.org wrote: Honestly if the choice comes down to an EDK2 upstream being git with 40 submodules, or a single SVN repository (with a git mirror), I'd rather have the single SVN repository. I'd never use SVN, but just use the git mirror. The maintainers would would still need to use SVN, but that's not my problem :):) The people that want to use SVN could use SVN, and those that want to use git (except for maintainers/committers :) could use git. You can commit to svn from git. git svn rebase git svn dcommit git svn info git svn makes svn based development sane, but it is inferior. It doesn't really support all git features. It also has a natsy gotcha where equivalent branch get artificially split. For example, my 'git-svn' at top-of-tree is never considered the same as origin/master. This prevents things like 'git merge' from being usable. Of course, 'git merge' can't be used with git svn anyhow... It also causes the source control history to be needlessly duplicated for the two branches. An example of how this wastes time is that I do my development based on the git origin/master branch. But, when it comes time to commit to svn, I checkout the git-svn branch, run git svn rebase, cherry-pick all the changes to the git-svn branch, and finally use git svn dcommit. Contrast this to just running 'git push'. -Jordan -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] Proposal of Git Repo Layout for EDKII project
On 2015-06-03 13:00:30, Jordan Justen wrote: But, even if you try to consider alternatives to submodules for composing platform trees, things get complicated. One idea, is to fork the EDK II master tree, and add submodules for your platform specific modules. To me this ends up with the worst of both worlds. 1. All git commands are difficult to use tree-wide, as expressed in this thread, and 2. You don't have the power to select only the EDK II modules that you need for your platform. Another idea is to fork the EDK II master tree and add your platform specific modules directly into the fork. In this case, you can still use all the git commands, but you once again can't select only the EDK II modules that you need for your platform. Other difficulties arise, such as, what if you have a chipset package that you want to share for multiple platforms? Unless all the platforms for that chipset live in the same branch, how do you easily share common code for those chipset packages? (Maybe a separate 'upstream' for the chipset code that the platforms merge in as needed?) Yet another idea that I've considered is trying to leverage git subtree. My idea was that the unified EDK II would remain the main upstream. I would setup an automated process to split each package off using git subtree, and push the separate repos. So, people who like the idea of git submodules can use them. The main disadvantage to them would be to get things upstream, they'd have to convert their commits to the merged unified tree. (git subtree might be able to help here as well, but there is no doubt that it would be more steps.) I never got the time to investigate if git subtree could work as required, but this text from the help page seems promising: split Extract a new, synthetic project history from the history of the prefix subtree. The new history includes only the commits (including merges) that affected prefix, and each of those commits now has the contents of prefix at the root of the project instead of in a subdirectory. Thus, the newly created history is suitable for export as a separate git repository. After splitting successfully, a single commit id is printed to stdout. This corresponds to the HEAD of the newly created tree, which you can manipulate however you want. Repeated splits of exactly the same history are guaranteed to be identical (ie. to produce the same commit ids). Because of this, if you add new commits and then re-split, the new commits will be attached as commits on top of the history you generated last time, so 'git merge' and friends will work as expected. Note that if you use '--squash' when you merge, you should usually not just '--rejoin' when you split. Note the Repeated splits part... -Jordan -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v3 2/8] BaseTools/EdkLogger: Support unit tests with a SILENT log level
This allows the unit tests to run without the errors logging to the screen. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Cc: Yingke D Liu yingke.d@intel.com --- BaseTools/Source/Python/Common/EdkLogger.py | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/BaseTools/Source/Python/Common/EdkLogger.py b/BaseTools/Source/Python/Common/EdkLogger.py index f048b61..8d6d426 100644 --- a/BaseTools/Source/Python/Common/EdkLogger.py +++ b/BaseTools/Source/Python/Common/EdkLogger.py @@ -32,6 +32,7 @@ INFO= 20 WARN= 30 QUIET = 40 ERROR = 50 +SILENT = 99 IsRaiseError = True @@ -39,7 +40,9 @@ IsRaiseError = True _ToolName = os.path.basename(sys.argv[0]) # For validation purpose -_LogLevels = [DEBUG_0, DEBUG_1, DEBUG_2, DEBUG_3, DEBUG_4, DEBUG_5, DEBUG_6, DEBUG_7, DEBUG_8, DEBUG_9, VERBOSE, WARN, INFO, ERROR, QUIET] +_LogLevels = [DEBUG_0, DEBUG_1, DEBUG_2, DEBUG_3, DEBUG_4, DEBUG_5, + DEBUG_6, DEBUG_7, DEBUG_8, DEBUG_9, VERBOSE, WARN, INFO, + ERROR, QUIET, SILENT] # For DEBUG level (All DEBUG_0~9 are applicable) _DebugLogger = logging.getLogger(tool_debug) @@ -235,6 +238,10 @@ def SetLevel(Level): _InfoLogger.setLevel(Level) _ErrorLogger.setLevel(Level) +def InitializeForUnitTest(): +Initialize() +SetLevel(SILENT) + ## Get current log level def GetLevel(): return _InfoLogger.getEffectiveLevel() -- 2.1.4 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v3 3/8] BaseTools/Tests: Add unit test for AutoGen.UniClassObject
This verifies that a UTF-16 data (with BOM) .uni file is successfully
read.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: Yingke D Liu yingke.d@intel.com
---
BaseTools/Tests/CheckUnicodeSourceFiles.py | 88 ++
BaseTools/Tests/PythonToolsTests.py| 4 +-
2 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 BaseTools/Tests/CheckUnicodeSourceFiles.py
diff --git a/BaseTools/Tests/CheckUnicodeSourceFiles.py
b/BaseTools/Tests/CheckUnicodeSourceFiles.py
new file mode 100644
index 000..0083ad8
--- /dev/null
+++ b/BaseTools/Tests/CheckUnicodeSourceFiles.py
@@ -0,0 +1,88 @@
+## @file
+# Unit tests for AutoGen.UniClassObject
+#
+# Copyright (c) 2015, Intel Corporation. All rights reserved.BR
+#
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD
License
+# which accompanies this distribution. The full text of the license may be
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+#
+
+##
+# Import Modules
+#
+import os
+import unittest
+
+import codecs
+
+import TestTools
+
+from Common.Misc import PathClass
+import AutoGen.UniClassObject as BtUni
+
+from Common import EdkLogger
+EdkLogger.InitializeForUnitTest()
+
+class Tests(TestTools.BaseToolsTest):
+
+SampleData = u'''
+#langdef en-US English
+#string STR_A #language en-US STR_A for en-US
+'''
+
+def EncodeToFile(self, encoding, string=None):
+if string is None:
+string = self.SampleData
+data = codecs.encode(string, encoding)
+path = 'input.uni'
+self.WriteTmpFile(path, data)
+return PathClass(self.GetTmpFilePath(path))
+
+def ErrorFailure(self, error, encoding, shouldPass):
+msg = error + ' should '
+if shouldPass:
+msg += 'not '
+msg += 'be generated for '
+msg += '%s data in a .uni file' % encoding
+self.fail(msg)
+
+def UnicodeErrorFailure(self, encoding, shouldPass):
+self.ErrorFailure('UnicodeError', encoding, shouldPass)
+
+def EdkErrorFailure(self, encoding, shouldPass):
+self.ErrorFailure('EdkLogger.FatalError', encoding, shouldPass)
+
+def CheckFile(self, encoding, shouldPass, string=None):
+path = self.EncodeToFile(encoding, string)
+try:
+BtUni.UniFileClassObject([path])
+if shouldPass:
+return
+except UnicodeError:
+if not shouldPass:
+return
+else:
+self.UnicodeErrorFailure(encoding, shouldPass)
+except EdkLogger.FatalError:
+if not shouldPass:
+return
+else:
+self.EdkErrorFailure(encoding, shouldPass)
+except Exception:
+pass
+
+self.EdkErrorFailure(encoding, shouldPass)
+
+def testUtf16InUniFile(self):
+self.CheckFile('utf_16', shouldPass=True)
+
+TheTestSuite = TestTools.MakeTheTestSuite(locals())
+
+if __name__ == '__main__':
+allTests = TheTestSuite()
+unittest.TextTestRunner().run(allTests)
diff --git a/BaseTools/Tests/PythonToolsTests.py
b/BaseTools/Tests/PythonToolsTests.py
index 6096e21..c953daf 100644
--- a/BaseTools/Tests/PythonToolsTests.py
+++ b/BaseTools/Tests/PythonToolsTests.py
@@ -1,7 +1,7 @@
## @file
# Unit tests for Python based BaseTools
#
-# Copyright (c) 2008, Intel Corporation. All rights reserved.BR
+# Copyright (c) 2008 - 2015, Intel Corporation. All rights reserved.BR
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD
License
@@ -24,6 +24,8 @@ def TheTestSuite():
suites = []
import CheckPythonSyntax
suites.append(CheckPythonSyntax.TheTestSuite())
+import CheckUnicodeSourceFiles
+suites.append(CheckUnicodeSourceFiles.TheTestSuite())
return unittest.TestSuite(suites)
if __name__ == '__main__':
--
2.1.4
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v3 4/8] BaseTools/UniClassObject: Verify valid UCS-2 chars in UTF-16 .uni files
Supplementary Plane characters can exist in UTF-16 files,
but they are not valid UCS-2 characters.
For example, refer to this python interpreter code:
import codecs
codecs.encode(u'\U00010300', 'utf-16')
'\xff\xfe\x00\xd8\x00\xdf'
Therefore the UCS-4 0x00010300 character is encoded as two
16-bit numbers (0xd800 0xdf00) in a little endian UTF-16
file.
For more information, see:
http://en.wikipedia.org/wiki/UTF-16#U.2B1_to_U.2B10
This means that our current BaseTools code could be allowing
unsupported UTF-16 characters be used. To fix this, we decode the file
using python's utf-16 decode support. Then we verify that each
character's code point is 0x or less.
v3: Based on Mike Kinney's feedback, we now read the whole file and
verify up-front that it contains valid UCS-2 characters. Thanks
also to Laszlo Ersek for pointing out the Supplementary Plane
characters.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: Yingke D Liu yingke.d@intel.com
Cc: Michael D Kinney michael.d.kin...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
---
BaseTools/Source/Python/AutoGen/UniClassObject.py | 84 ++-
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git a/BaseTools/Source/Python/AutoGen/UniClassObject.py
b/BaseTools/Source/Python/AutoGen/UniClassObject.py
index aa54f4f..66fdbf0 100644
--- a/BaseTools/Source/Python/AutoGen/UniClassObject.py
+++ b/BaseTools/Source/Python/AutoGen/UniClassObject.py
@@ -19,6 +19,7 @@
import Common.LongFilePathOs as os, codecs, re
import distutils.util
import Common.EdkLogger as EdkLogger
+import StringIO
from Common.BuildToolError import *
from Common.String import GetLineNo
from Common.Misc import PathClass
@@ -147,6 +148,33 @@ def GetLanguageCode(LangName, IsCompatibleMode, File):
EdkLogger.error(Unicode File Parser, FORMAT_INVALID, Invalid RFC 4646
language code : %s % LangName, File)
+## Ucs2Codec
+#
+# This is only a partial codec implementation. It only supports
+# encoding, and is primarily used to check that all the characters are
+# valid for UCS-2.
+#
+class Ucs2Codec(codecs.Codec):
+def __init__(self):
+self.__utf16 = codecs.lookup('utf-16')
+
+def encode(self, input, errors='strict'):
+for Char in input:
+if ord(Char) 0x:
+raise ValueError(Code Point too large to encode in UCS-2)
+return self.__utf16.encode(input)
+
+TheUcs2Codec = Ucs2Codec()
+def Ucs2Search(name):
+if name == 'ucs-2':
+return codecs.CodecInfo(
+name=name,
+encode=TheUcs2Codec.encode,
+decode=TheUcs2Codec.decode)
+else:
+return None
+codecs.register(Ucs2Search)
+
## StringDefClassObject
#
# A structure for language definition
@@ -209,7 +237,7 @@ class UniFileClassObject(object):
Lang = distutils.util.split_quoted((Line.split(u//)[0]))
if len(Lang) != 3:
try:
-FileIn = codecs.open(LongFilePath(File.Path), mode='rb',
encoding='utf-16').read()
+FileIn = self.OpenUniFile(LongFilePath(File.Path))
except UnicodeError, X:
EdkLogger.error(build, FILE_READ_FAILURE, File read
failure: %s % str(X), ExtraData=File);
except:
@@ -253,6 +281,58 @@ class UniFileClassObject(object):
self.OrderedStringDict[LangName][Item.StringName] =
len(self.OrderedStringList[LangName]) - 1
return True
+def OpenUniFile(self, FileName):
+#
+# Read file
+#
+try:
+UniFile = open(FileName, mode='rb')
+FileIn = UniFile.read()
+UniFile.close()
+except:
+EdkLogger.Error(build, FILE_OPEN_FAILURE, ExtraData=File)
+
+#
+# We currently only support UTF-16
+#
+Encoding = 'utf-16'
+
+self.VerifyUcs2Data(FileIn, FileName, Encoding)
+
+UniFile = StringIO.StringIO(FileIn)
+Info = codecs.lookup(Encoding)
+(Reader, Writer) = (Info.streamreader, Info.streamwriter)
+return codecs.StreamReaderWriter(UniFile, Reader, Writer)
+
+def VerifyUcs2Data(self, FileIn, FileName, Encoding):
+Ucs2Info = codecs.lookup('ucs-2')
+#
+# Convert to unicode
+#
+try:
+FileDecoded = codecs.decode(FileIn, Encoding)
+Ucs2Info.encode(FileDecoded)
+except:
+UniFile = StringIO.StringIO(FileIn)
+Info = codecs.lookup(Encoding)
+(Reader, Writer) = (Info.streamreader, Info.streamwriter)
+File = codecs.StreamReaderWriter(UniFile, Reader, Writer)
+LineNumber = 0
+ErrMsg = lambda Encoding, LineNumber: \
+ '%s contains invalid %s characters on line %d.' % \
+ (FileName, Encoding, LineNumber)
+while True:
+LineNumber
[edk2] [PATCH v3 8/8] OvmfPkg/PlatformDxe: Convert Platform.uni to UTF-8
This command was used to convert the file:
iconv -f UTF-16 -t UTF-8 \
-o OvmfPkg/PlatformDxe/Platform.uni \
OvmfPkg/PlatformDxe/Platform.uni
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Laszlo Ersek ler...@redhat.com
---
OvmfPkg/PlatformDxe/Platform.uni | Bin 3298 - 1648 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/OvmfPkg/PlatformDxe/Platform.uni b/OvmfPkg/PlatformDxe/Platform.uni
index
d8d5b0bb4de9c0632dc183369fa7d46f455e9143..6df865519f35e302430f1ad290729011fd4c9048
100644
GIT binary patch
literal 1648
zcmai!QE$^Q5Xaw_ztJ-1=yAX;)My2($-@UYg#2KjHk*?E{UbYj%=sf`1G9JEUQh
zN!Wq?rV%zPrf;-khDid@-50FU(Z;phZ%cr|+s@87=ra1IF;aLwGL^2N!qjDGZ
z_M=0*igRil;0_89-H;9+d8q_;1f=|=r%eY%s3j{2mF6vQS%9q(c%G}aMKhs
z3R-Sa3*H#u8le$6N(s7Y|9G@-f_|JZGD{FALNjLRl^4P*|HA)Foqs`P8qbPhLr
z65Q1yug5I~8j29c!wO-n7TbP*mW-5@Jsrs6y?rDNdPvFxY-wGQ0N~cA*VcBIlZom`
zvFdefzs7v$S{+wDK3VGpsTw-mRvJfCCjf#xPT~yd6Z^JG+k$G4(oW%638gPpCFpC
zIAySmAlW9OeyXrePYT=U%{%D7#*+Gx!lENf7lOJSKn!d3}OS)7Ggw2bN16{Y`#
zZ5ry2SzEh1-o@IF5H8n#p)(vbARz#X=Q*gAnr;FGt}3tA^WB={D%47+;55a*^lu
z@4%FNrMoS#6mqy4${X{qh+%?VsYl4g#TzP5di;Fqeoh-ME6N6x7wZGn5-IMJz`_
zE{))1+vaMSEK-(jvM9S@FnoM+ntY)UVdL(jeAo8%TiSRzJ!T*`V8-y-K-vQaKxL{
zqz+-nwNSkQkM9O+z@W7xjbhPMHt0i@84pN(4LhJhyw!M*k-m)MqU2T5n-jVM6IcX
z5;Usu#Z46pv8(E-QucZ3=HEwlC!iyh(wR~aZi@2Js?bC=erZ7oQ*Cb;|AhOW
znL|C)Q-9N_pn_-N)U3#8SZk8fA_kDyc~PYq-;t=cdI@6sW*;ixI!@{k(k%x$M
zt{j;%+}N|;xWfFGIgb9sog?~B)kDrDm=1GMJ^-hq-wk8L%A*7QI1@yQDXqkTqu1
zG%HKd}4H1u;N0}yZ8|hTqwS-9}G5I1)KiZ7VG7o!Adfb}tUAfu_+cOy*BN36Lp
MIoHK=u$M11Ja-Rz5oCK
literal 3298
zcmb`J+fP$L5XR@(#Q)(0Uc3Qne37ULm!geA2`ws5OUU1q!-dtKXv?-#6Pmrx)l^
zVw#@4CYx~^Udu3{URWme@0UhN23VziaDiS60QF74LF*0Zi%*aX=p%s!=kZ7=PW
zy|EYcPpoa{w4bbjjAqIw3claS|@WUfSDi=LCIyw8;J#1o}#IkKPciiS4j1i5yw#
zqqe29ow}d+O7J3%U;(j(EnzYMiHsbb|gddb@68z_@`8oo0eW+s7@=GO_`ZTDxW6
z5cz}|p_08Gy}oN}Fw(9*b1iy9MjhwuXdeJHDA;3A=|Jf-*$#Gu`5R*-8qtAYcRDF
zPzsrPz05y4)5tnA`*y8r`;5QLVM^@AebC}7bn~a|fkv9-1^FrWoNT4c(otfc;Pv
z)#*FThX@Jt4`dcGHE?#@)oJ)bpL4T0U?{rSQiT?L}J^yDt-nZOMdJg-{kaT;L37
zgOrj$j@zKVPz977yRQHV=I?vJ$9{VNu0C^4+mR#$`O3;8V3VX3OyGlwQgGd}Fu
zCFXMtc?`%x`ag4HCO0~-$*O0Tr8(eCKqZb*r#J;gETot#d@eY=R?1=d?TBW1n
z)=wA-yXIuGhLmJvHAo#GtDR@GpIH%dWpHU~C7hyU-!nZ?d+wzJ~@V6vb{f(^|{0$
zF*$cmh#g17bU@s;vs2}g3G2tiM^W#1BnN0zHuUb0-tmZvi{kI(UX4}O#Mh9w%D#?|
z=CdZ)Teg2N#gTKnw{f2kZi!JXVdB#PV?T@T~4EQKas2l+ljMwg9yr-YxqrT%83*v
zuFdR=nHG=-w$x9p~)ty$e;S|bADijRae1(s?*j=;v9H8WJXrL5sK7(_RoC+?
zufhT2dR7Tm5L!WLH|59jf(N@;StrfL#?+kyO5??9b6(F0dwHy-nOzpR`-iTaEgV
zOi%{o{=Lt$#i(;!)ddu*F@#*LQzK42gO@!PXNoZ#0y+w}^VWg+Y^c(0HDVx7s
zR(Tm~^)3=4*8c@--D~ATqa1Gz-NuWUHM5L){*L|zJ}Lv-MeCjUJtr`byl%n+)bE?
zXKYT-sP{zK*9I^pzH`Doq`DJWq?)LEMcJd*#gLwOB|a)|=ZEI`|0H)d(t)ZJ@UNX
zOgHSGz{31SzxJJNq!gKOx1`MdL_-lBU6sZt?yKT$cyE+m?`r)_VJr74xCYiP-Pw
zPBHc~ym!UvTSP)pNQXG!iyc=YKnV^`VH+YyA;C^sd$R`;w$EoUO8f=Vi}nms${6
z-j%vx`oud(h8JKLG-8da`u|};71n%(0d;4AUIxqY4QG{RK^VW=~h(!aJm16yL8U
k-gA;zT^qvNXb*HJya`sJE5@~tz0~77_B{JLWV(0%07EhSy8r+H
--
2.1.4
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v3 0/8] Support UTF-8 in .uni string files
https://github.com/jljusten/edk2.git utf8-v3 v3: * v2 fixed the USC-2 issue with UTF-16 file by 'accident'. Now this is done in separate patches. (Patches 3 4) * Validate entire file by loading the entire contents (mdkinney) * Add stub version of ucs-2 codec to verify unicode file contents are valid USC-2 characters. v2: * Drop .utf8 extension. Use .uni file for UTF-8 data (mdkinney) The UTF-16 .uni files are fairly annoying to work with: * They must be checked in as 'binary' files * It is difficult to produce a diff of changes * UTF-8 is more likely to be supported by text editors This series allows .uni files to contain UTF-8 (or, as before, UTF-16) string data. If the UTF-16 LE or BE BOM is found, then the file is read as UTF-16. Otherwise, it is treated as UTF-8. Jordan Justen (8): BaseTools/Tests: Always add BaseTools source to import path BaseTools/EdkLogger: Support unit tests with a SILENT log level BaseTools/Tests: Add unit test for AutoGen.UniClassObject BaseTools/UniClassObject: Verify valid UCS-2 chars in UTF-16 .uni files BaseTools/Tests: Verify unsupported UTF-16 are rejected BaseTools/UniClassObject: Support UTF-8 string data in .uni files BaseTools/Tests: Verify 32-bit UTF-8 chars are rejected OvmfPkg/PlatformDxe: Convert Platform.uni to UTF-8 BaseTools/Source/Python/AutoGen/UniClassObject.py | 87 ++- BaseTools/Source/Python/Common/EdkLogger.py | 9 +- BaseTools/Tests/CheckUnicodeSourceFiles.py| 128 ++ BaseTools/Tests/PythonToolsTests.py | 4 +- BaseTools/Tests/RunTests.py | 2 - BaseTools/Tests/TestTools.py | 9 +- OvmfPkg/PlatformDxe/Platform.uni | Bin 3298 - 1648 bytes 7 files changed, 232 insertions(+), 7 deletions(-) create mode 100644 BaseTools/Tests/CheckUnicodeSourceFiles.py -- 2.1.4 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v3 5/8] BaseTools/Tests: Verify unsupported UTF-16 are rejected
Supplementary Plane characters can exist in UTF-16 files,
but they are not valid UCS-2 characters.
For example, this python interpreter code:
import codecs
codecs.encode(u'\U00010300', 'utf-16')
'\xff\xfe\x00\xd8\x00\xdf'
Therefore the UCS-4 0x00010300 character is encoded as two
16-bit numbers (0xd800 0xdf00) in a little endian UTF-16
file.
For more information, see:
http://en.wikipedia.org/wiki/UTF-16#U.2B1_to_U.2B10
This test checks to make sure that BaseTools will reject these
characters in UTF-16 files.
This test was fixed by the previous commit:
BaseTools/UniClassObject: Verify valid UCS-2 chars in UTF-16 .uni files
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: Yingke D Liu yingke.d@intel.com
Cc: Michael D Kinney michael.d.kin...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
---
BaseTools/Tests/CheckUnicodeSourceFiles.py | 15 +++
1 file changed, 15 insertions(+)
diff --git a/BaseTools/Tests/CheckUnicodeSourceFiles.py
b/BaseTools/Tests/CheckUnicodeSourceFiles.py
index 0083ad8..39fd2fe 100644
--- a/BaseTools/Tests/CheckUnicodeSourceFiles.py
+++ b/BaseTools/Tests/CheckUnicodeSourceFiles.py
@@ -81,6 +81,21 @@ class Tests(TestTools.BaseToolsTest):
def testUtf16InUniFile(self):
self.CheckFile('utf_16', shouldPass=True)
+def testSupplementaryPlaneUnicodeCharInUtf16File(self):
+#
+# Supplementary Plane characters can exist in UTF-16 files,
+# but they are not valid UCS-2 characters.
+#
+# This test makes sure that BaseTools rejects these characters
+# if seen in a .uni file.
+#
+data = u'''
+#langdef en-US English
+#string STR_A #language en-US CodePoint (\U00010300) 0x
+'''
+
+self.CheckFile('utf_16', shouldPass=False, string=data)
+
TheTestSuite = TestTools.MakeTheTestSuite(locals())
if __name__ == '__main__':
--
2.1.4
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v3 6/8] BaseTools/UniClassObject: Support UTF-8 string data in .uni files
This allows .uni input files to be encoded with UTF-8. Today, we only support UTF-16 encoding. The strings are still converted to UCS-2 data for use in EDK II modules. (This is the only unicode character format supported by UEFI and EDK II.) Although UTF-8 would allow any UCS-4 character to be present in the source file, we restrict the entire file to the UCS-2 range. (Including comments.) This allows the files to be converted to UTF-16 if needed. v2: * Drop .utf8 extension. Use .uni file for UTF-8 data (mdkinney) * Merge in 'BaseTools/UniClassObject: Verify string data is 16-bit' commit v3: * Restrict the entire file's characters (including comments) to the UCS-2 range in addition to string data. (mdkinney) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Cc: Yingke D Liu yingke.d@intel.com Cc: Michael D Kinney michael.d.kin...@intel.com --- BaseTools/Source/Python/AutoGen/UniClassObject.py | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/BaseTools/Source/Python/AutoGen/UniClassObject.py b/BaseTools/Source/Python/AutoGen/UniClassObject.py index 66fdbf0..6ccaef0 100644 --- a/BaseTools/Source/Python/AutoGen/UniClassObject.py +++ b/BaseTools/Source/Python/AutoGen/UniClassObject.py @@ -293,9 +293,12 @@ class UniFileClassObject(object): EdkLogger.Error(build, FILE_OPEN_FAILURE, ExtraData=File) # -# We currently only support UTF-16 +# Detect Byte Order Mark at beginning of file. Default to UTF-8 # -Encoding = 'utf-16' +Encoding = 'utf-8' +if (FileIn.startswith(codecs.BOM_UTF16_BE) or +FileIn.startswith(codecs.BOM_UTF16_LE)): +Encoding = 'utf-16' self.VerifyUcs2Data(FileIn, FileName, Encoding) -- 2.1.4 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v3 1/8] BaseTools/Tests: Always add BaseTools source to import path
This allows unit tests to easily include BaseTools python modules. This is very useful for writing unit tests. Actually, previously, we would do this when RunTests.py was executed, so unit tests could easily import BaseTools modules, so long as they were executed via RunTests. This change allows running the unit test files individually which can be faster for developing the new unit test cases. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Cc: Yingke D Liu yingke.d@intel.com --- BaseTools/Tests/RunTests.py | 2 -- BaseTools/Tests/TestTools.py | 9 - 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/BaseTools/Tests/RunTests.py b/BaseTools/Tests/RunTests.py index e8ca2d0..0dd6563 100644 --- a/BaseTools/Tests/RunTests.py +++ b/BaseTools/Tests/RunTests.py @@ -21,8 +21,6 @@ import unittest import TestTools -sys.path.append(TestTools.PythonSourceDir) - def GetCTestSuite(): import CToolsTests return CToolsTests.TheTestSuite() diff --git a/BaseTools/Tests/TestTools.py b/BaseTools/Tests/TestTools.py index ac009db..27afd79 100644 --- a/BaseTools/Tests/TestTools.py +++ b/BaseTools/Tests/TestTools.py @@ -1,7 +1,7 @@ ## @file # Utility functions and classes for BaseTools unit tests # -# Copyright (c) 2008 - 2012, Intel Corporation. All rights reserved.BR +# Copyright (c) 2008 - 2015, Intel Corporation. All rights reserved.BR # # This program and the accompanying materials # are licensed and made available under the terms and conditions of the BSD License @@ -31,6 +31,13 @@ CSourceDir = os.path.join(BaseToolsDir, 'Source', 'C') PythonSourceDir = os.path.join(BaseToolsDir, 'Source', 'Python') TestTempDir = os.path.join(TestsDir, 'TestTempDir') +if PythonSourceDir not in sys.path: +# +# Allow unit tests to import BaseTools python modules. This is very useful +# for writing unit tests. +# +sys.path.append(PythonSourceDir) + def MakeTheTestSuite(localItems): tests = [] for name, item in localItems.iteritems(): -- 2.1.4 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v3 7/8] BaseTools/Tests: Verify 32-bit UTF-8 chars are rejected
Since UTF-8 .uni unicode files might contain strings with unicode code
points larger than 16-bits, and UEFI only supports UCS-2 characters,
we need to make sure that BaseTools rejects these characters in UTF-8
.uni source files.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: Yingke D Liu yingke.d@intel.com
---
BaseTools/Tests/CheckUnicodeSourceFiles.py | 25 +
1 file changed, 25 insertions(+)
diff --git a/BaseTools/Tests/CheckUnicodeSourceFiles.py
b/BaseTools/Tests/CheckUnicodeSourceFiles.py
index 39fd2fe..1b17377 100644
--- a/BaseTools/Tests/CheckUnicodeSourceFiles.py
+++ b/BaseTools/Tests/CheckUnicodeSourceFiles.py
@@ -96,6 +96,31 @@ class Tests(TestTools.BaseToolsTest):
self.CheckFile('utf_16', shouldPass=False, string=data)
+def test32bitUnicodeCharInUtf8File(self):
+data = u'''
+#langdef en-US English
+#string STR_A #language en-US CodePoint (\U00010300) 0x
+'''
+
+self.CheckFile('utf_16', shouldPass=False, string=data)
+
+def test32bitUnicodeCharInUtf8File(self):
+data = u'''
+#langdef en-US English
+#string STR_A #language en-US CodePoint (\U00010300) 0x
+'''
+
+self.CheckFile('utf_8', shouldPass=False, string=data)
+
+def test32bitUnicodeCharInUtf8Comment(self):
+data = u'''
+// Even in comments, we reject non-UCS-2 chars: \U00010300
+#langdef en-US English
+#string STR_A #language en-US A
+'''
+
+self.CheckFile('utf_8', shouldPass=False, string=data)
+
TheTestSuite = TestTools.MakeTheTestSuite(locals())
if __name__ == '__main__':
--
2.1.4
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v3 4/8] BaseTools/UniClassObject: Verify valid UCS-2 chars in UTF-16 .uni files
On 2015-06-01 02:46:53, Laszlo Ersek wrote:
On 06/01/15 09:31, Jordan Justen wrote:
Supplementary Plane characters can exist in UTF-16 files,
but they are not valid UCS-2 characters.
For example, refer to this python interpreter code:
import codecs
codecs.encode(u'\U00010300', 'utf-16')
'\xff\xfe\x00\xd8\x00\xdf'
Therefore the UCS-4 0x00010300 character is encoded as two
16-bit numbers (0xd800 0xdf00) in a little endian UTF-16
file.
For more information, see:
http://en.wikipedia.org/wiki/UTF-16#U.2B1_to_U.2B10
This means that our current BaseTools code could be allowing
unsupported UTF-16 characters be used. To fix this, we decode the file
using python's utf-16 decode support. Then we verify that each
character's code point is 0x or less.
v3: Based on Mike Kinney's feedback, we now read the whole file and
verify up-front that it contains valid UCS-2 characters. Thanks
also to Laszlo Ersek for pointing out the Supplementary Plane
characters.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: Yingke D Liu yingke.d@intel.com
Cc: Michael D Kinney michael.d.kin...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
---
BaseTools/Source/Python/AutoGen/UniClassObject.py | 84
++-
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git a/BaseTools/Source/Python/AutoGen/UniClassObject.py
b/BaseTools/Source/Python/AutoGen/UniClassObject.py
index aa54f4f..66fdbf0 100644
--- a/BaseTools/Source/Python/AutoGen/UniClassObject.py
+++ b/BaseTools/Source/Python/AutoGen/UniClassObject.py
@@ -19,6 +19,7 @@
import Common.LongFilePathOs as os, codecs, re
import distutils.util
import Common.EdkLogger as EdkLogger
+import StringIO
from Common.BuildToolError import *
from Common.String import GetLineNo
from Common.Misc import PathClass
@@ -147,6 +148,33 @@ def GetLanguageCode(LangName, IsCompatibleMode, File):
EdkLogger.error(Unicode File Parser, FORMAT_INVALID, Invalid RFC
4646 language code : %s % LangName, File)
+## Ucs2Codec
+#
+# This is only a partial codec implementation. It only supports
+# encoding, and is primarily used to check that all the characters are
+# valid for UCS-2.
+#
+class Ucs2Codec(codecs.Codec):
+def __init__(self):
+self.__utf16 = codecs.lookup('utf-16')
+
+def encode(self, input, errors='strict'):
+for Char in input:
+if ord(Char) 0x:
+raise ValueError(Code Point too large to encode in UCS-2)
+return self.__utf16.encode(input)
I could be missing some context, but the wikipedia article referenced at
the top says that
The official Unicode standard says that no UTF forms [...] can encode
[U+D800 to U+DFFF] code points.
However UCS-2, UTF-8 [...] can encode [U+D800 to U+DFFF] code points
in trivial and obvious ways [...]
So basically it is possible to construct a UTF-8 file that (albeit
violating the unicode standard) will result in U+D800 to U+DFFF code
*points* when parsed. Then (I think) these would be turned into UCS2
code *units* with identical numeric values. Which, I think, would be wrong.
Also, the same seems to apply to a UTF-16 source:
It is possible to unambiguously encode them in UTF-16 by using a code
unit equal to the code point, as long as no sequence of two code
units can be interpreted as a legal surrogate pair (that is, as long
as a high surrogate is never followed by a low surrogate). The
majority of UTF-16 encoder and decoder implementations translate
between encodings as though this were the case.
Shouldn't we accept code points *only* in U+ to U+D7FF and U+E000
to U+? The article says
I think you are right. Under U+D800 to U+DFFF it says: The Unicode
standard permanently reserves these code point values for UTF-16
encoding of the high and low surrogates, and they will never be
assigned a character, so there should be no reason to encode them.
So, I guess there is no valid reason to accept them as input code
points.
-Jordan
Both UTF-16 and UCS-2 encode code points in this range as single
16-bit code units that are numerically equal to the corresponding
code points. These code points in the BMP are the /only/ code points
that can be represented in UCS-2. Modern text almost exclusively
consists of these code points.
For example,
printf '%b' '\x01\xD8\x24\x00'
creates two UTF-16 code units (in LE representation):
D801 0024
This is not a valid surrogate pair (there is no low surrogate). Does
your code (or the underlying python machinery) reject the output of the
above printf invocation?
For example, iconv rejects it:
$ printf '%b' '\x01\xD8\x24\x00' | iconv -f UTF-16LE -t UCS-2
iconv: illegal input sequence at position 0
Hm... let's see
Re: [edk2] How to send patches against UTF-16 .uni files for review?
On 2015-05-29 09:07:19, Laszlo Ersek wrote: On 05/29/15 17:46, Bruce Cran wrote: I have some fixes to Vlv2TbltDevicePkg/PlatformSetupDxe/VfrStrings.uni such as changing Congfiguration to Configuration, but since it's UTF-16 git treats it as binary. How should we send patches for such files to edk2-devel for review? Jordan tried to introduce UTF-8 encoded UNI files recently. I'm uncertain about the result of that work. I hope to send out v3 soon based on Mike's feedback. -Jordan With the current UCS-2 encoded UNI files, you can send a binary (approximately: uuencoded) patch with git. (Git-format-patch will handle that automatically.) Then reviewers can apply (or pull, if you push them first) the patches. Using the hints discussed earlier in http://thread.gmane.org/gmane.comp.bios.tianocore.devel/6351 once applied, the local commits can be shown / reviewed easily. Review comments cannot really be tied to the relevant parts of the (approximately uuencoded) patch, unfortunately. Alternatively, the traditional (non-)solution has been to post the modified UNI file in full, as an attachment... So, my recommendation: - employ the hints from under the above link - review your own work in git - push your branch to github - post the (binary) patches, reference your branch on github - wait for reviews Thanks Laszlo -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/DxeCore: Fixed build error
For your attached patch:
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
On 2015-05-28 03:26:13, Zeng, Star wrote:
Olivier,
Thanks, see the attached patch.
Star
-Original Message-
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Thursday, May 28, 2015 5:40 PM
To: edk2-devel@lists.sourceforge.net; Justen, Jordan L
Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeCore: Fixed build error
Yes, that would be another valid solution. Star, do you want to make the
patch?
-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: 28 May 2015 02:20
To: edk2-devel@lists.sourceforge.net; Justen, Jordan L
Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeCore: Fixed build error
To eliminate the confusion, how about to update the return type of
GetProfileMemoryIndex() from EFI_MEMORY_TYPE to UINT32 or UINTN?
Thanks,
Star
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Thursday, May 28, 2015 2:59 AM
To: Justen, Jordan L
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeCore: Fixed build error
On 05/27/15 20:32, Jordan Justen wrote:
On 2015-05-27 08:32:52, Olivier Martin wrote:
ARM toolchain raises the build error: enumerated type mixed with
another type
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
---
MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
b/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
index 2c6713f..b23a056 100644
--- a/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
+++ b/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
@@ -789,7 +789,7 @@ GetProfileMemoryIndex (
if ((UINT32) MemoryType = MEMORY_TYPE_OS_RESERVED_MIN) {
return EfiMaxMemoryType;
} else if ((UINT32) MemoryType = MEMORY_TYPE_OEM_RESERVED_MIN) {
-return EfiMaxMemoryType + 1;
+return (EFI_MEMORY_TYPE)(EfiMaxMemoryType + 1);
The code style would want a space after the cast close parens, right?
(It would, and it is so wrong! Obligatory reference:
https://github.com/tianocore/edk2/commit/71914406. This is the one and only
bit in the code style that is entirely harmful.)
Laszlo
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
} else {
return MemoryType;
}
--
2.1.1
-
- ___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England Wales, Company No: 2557590 ARM Holdings plc,
Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England
Wales, Company No: 2548782
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v2] BaseTools/Conf: Don't support upper case nasm extensions
For *.asm and *.s, there have been cases of *.Asm and *.S files, but since the nasm extensions are new, we don't need to support the upper case extensions. In other words, remove .Nasm and .NASM. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Cc: Liming Gao liming@intel.com --- BaseTools/Conf/build_rule.template | 4 ++-- BaseTools/Conf/tools_def.template | 8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template index f1edf3a..e5467cc 100644 --- a/BaseTools/Conf/build_rule.template +++ b/BaseTools/Conf/build_rule.template @@ -194,7 +194,7 @@ [Nasm-Assembly-Code-File.COMMON.COMMON] InputFile -?.nasm, ?.Nasm, ?.NASM +?.nasm ExtraDependency $(MAKE_FILE) @@ -479,7 +479,7 @@ [Nasm-to-Binary-Code-File] InputFile -?.nasmb, ?.NASMB +?.nasmb ExtraDependency $(MAKE_FILE) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index ad34a3d..fd7b4b5 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -6276,7 +6276,7 @@ NOOPT_MYTOOLS_IPF_DLINK_FLAGS= /NOLOGO /NODEFAULTLIB /LTCG /DLL /OPT # XCODE32 - Xcode 3.2 Tools (Snow Leopard) *_XCODE32_*_*_FAMILY= GCC *_XCODE32_*_*_BUILDRULEFAMILY = XCODE -*_XCODE32_*_*_BUILDRULEORDER= S s nasm Nasm NASM +*_XCODE32_*_*_BUILDRULEORDER= S s nasm *_XCODE32_*_ASL_PATH = /usr/bin/iasl @@ -6386,7 +6386,7 @@ RELEASE_XCODE32_ARM_CC_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -mthumb-inter # CLANG - clang that produce Mach-O with EFI x86_64 ABI *_XCLANG_*_*_FAMILY= GCC *_XCLANG_*_*_BUILDRULEFAMILY = XCODE -*_XCLANG_*_*_BUILDRULEORDER= S s nasm Nasm NASM +*_XCLANG_*_*_BUILDRULEORDER= S s nasm *_XCLANG_*_ASL_PATH = /usr/bin/iasl @@ -6450,7 +6450,7 @@ RELEASE_XCLANG_X64_CC_FLAGS = -ccc-host-triple x86_64-pc-win32-macho -c-Os *_XCODE5_*_*_FAMILY= GCC *_XCODE5_*_*_BUILDRULEFAMILY = XCODE -*_XCODE5_*_*_BUILDRULEORDER= S s nasm Nasm NASM +*_XCODE5_*_*_BUILDRULEORDER= S s nasm *_XCODE5_*_ASL_PATH = /usr/bin/iasl @@ -6947,4 +6947,4 @@ RELEASE_ARMLINUXGCC_AARCH64_CC_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC # # Build rule order # -*_*_*_*_BUILDRULEORDER = nasm Nasm NASM asm Asm ASM S s +*_*_*_*_BUILDRULEORDER = nasm asm Asm ASM S s -- 2.1.4 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v2] BaseTools/Conf: Don't support upper case nasm extensions
On 2015-05-28 08:35:40, Hauch, Larry wrote: Hi Jordan, So if we remove .Nasm and .NASM and someone accidentally uses these in an INF file, should the build break? I think so, but, I can't think of a scenario where the extra extensions are helpful. I guess on Windows someone might be able to put 1.nasm in the .inf, and check in 1.Nasm without noticing a build error. Then if someone tried to build on Linux, they will see an error. Yet, the same thing would happen if the .Nasm extension was in the Conf files, since they still would have put 1.nasm in the .inf. So, the only thing this adds is that they can add 1.Nasm to the .inf so long as they also check in 1.Nasm. I don't think this is too useful. -Jordan -Original Message- From: Jordan Justen [mailto:jordan.l.jus...@intel.com] Sent: Thursday, May 28, 2015 8:14 AM To: edk2-devel@lists.sourceforge.net Subject: [edk2] [PATCH v2] BaseTools/Conf: Don't support upper case nasm extensions For *.asm and *.s, there have been cases of *.Asm and *.S files, but since the nasm extensions are new, we don't need to support the upper case extensions. In other words, remove .Nasm and .NASM. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com Cc: Liming Gao liming@intel.com --- BaseTools/Conf/build_rule.template | 4 ++-- BaseTools/Conf/tools_def.template | 8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template index f1edf3a..e5467cc 100644 --- a/BaseTools/Conf/build_rule.template +++ b/BaseTools/Conf/build_rule.template @@ -194,7 +194,7 @@ [Nasm-Assembly-Code-File.COMMON.COMMON] InputFile -?.nasm, ?.Nasm, ?.NASM +?.nasm ExtraDependency $(MAKE_FILE) @@ -479,7 +479,7 @@ [Nasm-to-Binary-Code-File] InputFile -?.nasmb, ?.NASMB +?.nasmb ExtraDependency $(MAKE_FILE) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index ad34a3d..fd7b4b5 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -6276,7 +6276,7 @@ NOOPT_MYTOOLS_IPF_DLINK_FLAGS= /NOLOGO /NODEFAULTLIB /LTCG /DLL /OPT # XCODE32 - Xcode 3.2 Tools (Snow Leopard) *_XCODE32_*_*_FAMILY= GCC *_XCODE32_*_*_BUILDRULEFAMILY = XCODE -*_XCODE32_*_*_BUILDRULEORDER= S s nasm Nasm NASM +*_XCODE32_*_*_BUILDRULEORDER= S s nasm *_XCODE32_*_ASL_PATH = /usr/bin/iasl @@ -6386,7 +6386,7 @@ RELEASE_XCODE32_ARM_CC_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -mthumb-inter # CLANG - clang that produce Mach-O with EFI x86_64 ABI *_XCLANG_*_*_FAMILY= GCC *_XCLANG_*_*_BUILDRULEFAMILY = XCODE -*_XCLANG_*_*_BUILDRULEORDER= S s nasm Nasm NASM +*_XCLANG_*_*_BUILDRULEORDER= S s nasm *_XCLANG_*_ASL_PATH = /usr/bin/iasl @@ -6450,7 +6450,7 @@ RELEASE_XCLANG_X64_CC_FLAGS = -ccc-host-triple x86_64-pc-win32-macho -c-Os *_XCODE5_*_*_FAMILY= GCC *_XCODE5_*_*_BUILDRULEFAMILY = XCODE -*_XCODE5_*_*_BUILDRULEORDER= S s nasm Nasm NASM +*_XCODE5_*_*_BUILDRULEORDER= S s nasm *_XCODE5_*_ASL_PATH = /usr/bin/iasl @@ -6947,4 +6947,4 @@ RELEASE_ARMLINUXGCC_AARCH64_CC_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC # # Build rule order # -*_*_*_*_BUILDRULEORDER = nasm Nasm NASM asm Asm ASM S s +*_*_*_*_BUILDRULEORDER = nasm asm Asm ASM S s -- 2.1.4 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] Replacement EDK2 email list coming soon
On 2015-05-27 10:20:09, Laszlo Ersek wrote: On 05/27/15 18:06, Andrew Fish wrote: On May 27, 2015, at 1:52 AM, Laszlo Ersek ler...@redhat.com mailto:ler...@redhat.com wrote: Access on the web looks like a step forward (eg. it provides syntax highlighting), but it's actually a small step at a steep price. The price is that a web browser (and a central server) are required. “Stone Knives and bearskins” aside, why is a web browser bad? Ultimately, I can only say that I've found web apps very limiting when engaging in technical discussion. See also: this thread right here. ... Actual discussion happening. Can you imagine trying to do the same on a web forum? ... Little barrier to entry to the discussion. (An email account.) I happen to agree with Laszlo. We should retain the ability for people to run git format-patch/send-email to contribute. If we adopt some web based system, we should note that we are going to cut some people out of that loop. I've seen Gerrit a little, but I've not actually worked with it. Regarding what I saw, I wasn't particularly impressed (nor concerned). It didn't appear to bring all that much beyond email reviews. -Jordan -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/DxeCore: Fixed build error
On 2015-05-27 08:32:52, Olivier Martin wrote:
ARM toolchain raises the build error: enumerated
type mixed with another type
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
---
MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
b/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
index 2c6713f..b23a056 100644
--- a/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
+++ b/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
@@ -789,7 +789,7 @@ GetProfileMemoryIndex (
if ((UINT32) MemoryType = MEMORY_TYPE_OS_RESERVED_MIN) {
return EfiMaxMemoryType;
} else if ((UINT32) MemoryType = MEMORY_TYPE_OEM_RESERVED_MIN) {
-return EfiMaxMemoryType + 1;
+return (EFI_MEMORY_TYPE)(EfiMaxMemoryType + 1);
The code style would want a space after the cast close parens, right?
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
} else {
return MemoryType;
}
--
2.1.1
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v2] MdeModulePkg: Regular expression protocol
On 2015-05-20 14:08:40, Jonathan Doman wrote:
+STATIC
+EFI_STATUS
+PosixExtendedMatch (
+ IN CHAR16 *String,
+ IN CHAR16 *Pattern,
+ OUT BOOLEAN *Result,
+ OUT EFI_REGEX_CAPTURE **Captures, OPTIONAL
+ OUT UINTN *CapturesCount
+ )
+{
+ REG_EX_HANDLE Regex;
+ CHAR8 *AsciiString;
+ CHAR8 *AsciiPattern;
+ EFI_STATUSStatus;
+
+ ASSERT (String != NULL);
+ ASSERT (Pattern != NULL);
+ ASSERT (Result != NULL);
+ ASSERT (CapturesCount != NULL);
+
+ //
+ // Our POSIX Extended library only supports ASCII input
+ //
+ AsciiString = AllocatePool (StrLen (String) + 1);
+ if (AsciiString == NULL) {
+return EFI_OUT_OF_RESOURCES;
+ }
+ UnicodeStrToAsciiStr (String, AsciiString);
I don't think this matches the spec.
+ AsciiPattern = AllocatePool (StrLen (Pattern) + 1);
+ if (AsciiPattern == NULL) {
+FreePool (AsciiString);
+return EFI_OUT_OF_RESOURCES;
+ }
+ UnicodeStrToAsciiStr (Pattern, AsciiPattern);
I don't think this matches the spec.
+ //
+ // Compile and run the regex
+ //
+ Status = RegExCompile (Regex, AsciiPattern);
+
+ if (!EFI_ERROR (Status)) {
+*Result = RegExMatch (Regex, AsciiString, NULL, 0);
+ } else {
+*Result = FALSE;
+ }
+
+ //
+ // Write out the results
+ //
+ if (!*Result) {
+if (Captures != NULL) {
+ *Captures = NULL;
+}
+*CapturesCount = 0;
+ } else {
+//
+// Doesn't support sub-expression capture groups yet
Doesn't meet the spec. :)
-Jordan
+//
+if (Captures != NULL) {
+ *Captures = AllocatePool (sizeof(EFI_REGEX_CAPTURE));
+ (*Captures)[0].CapturePtr = String;
+ (*Captures)[0].Length = StrLen (String);
+}
+*CapturesCount = 1;
+ }
+
+ RegExFree (Regex);
+
+ FreePool (AsciiPattern);
+ FreePool (AsciiString);
+
+ return Status;
+}
+
+/**
+ Returns information about the regular expression syntax types supported
+ by the implementation.
+
+ This A pointer to the EFI_REGULAR_EXPRESSION_PROTOCOL
+ instance.
+
+ RegExSyntaxTypeListSize On input, the size in bytes of
RegExSyntaxTypeList.
+ On output with a return code of EFI_SUCCESS, the
+ size in bytes of the data returned in
+ RegExSyntaxTypeList. On output with a return code
+ of EFI_BUFFER_TOO_SMALL, the size of
+ RegExSyntaxTypeList required to obtain the list.
+
+ RegExSyntaxTypeList A caller-allocated memory buffer filled by the
+ driver with one EFI_REGEX_SYNTAX_TYPE element
+ for each supported Regular expression syntax
+ type. The list must not change across multiple
+ calls to the same driver. The first syntax
+ type in the list is the default type for the
+ driver.
+
+ @retval EFI_SUCCESSThe regular expression syntax types list
+ was returned successfully.
+ @retval EFI_UNSUPPORTEDThe service is not supported by this driver.
+ @retval EFI_DEVICE_ERROR The list of syntax types could not be
+ retrieved due to a hardware or firmware
error.
+ @retval EFI_BUFFER_TOO_SMALL The buffer RegExSyntaxTypeList is too small
+ to hold the result.
+ @retval EFI_INVALID_PARAMETER RegExSyntaxTypeListSize is NULL
+
+**/
+EFI_STATUS
+EFIAPI
+RegularExpressionGetInfo (
+ IN EFI_REGULAR_EXPRESSION_PROTOCOL *This,
+ IN OUT UINTN *RegExSyntaxTypeListSize,
+ OUTEFI_REGEX_SYNTAX_TYPE *RegExSyntaxTypeList
+ )
+{
+ UINTN SyntaxSize;
+ UINTN Index;
+
+ if (This == NULL || RegExSyntaxTypeListSize == NULL || RegExSyntaxTypeList
== NULL) {
+return EFI_INVALID_PARAMETER;
+ }
+
+ SyntaxSize = ARRAY_SIZE (mSupportedSyntaxes) *
sizeof(**mSupportedSyntaxes);
+
+ if (*RegExSyntaxTypeListSize SyntaxSize) {
+*RegExSyntaxTypeListSize = SyntaxSize;
+return EFI_BUFFER_TOO_SMALL;
+ }
+
+ for (Index = 0; Index ARRAY_SIZE (mSupportedSyntaxes); ++Index) {
+CopyMem (RegExSyntaxTypeList[Index], mSupportedSyntaxes[Index],
sizeof(**mSupportedSyntaxes));
+ }
+ *RegExSyntaxTypeListSize = SyntaxSize;
+
+ return EFI_SUCCESS;
+}
+
+/**
+ Checks if the input string matches to the regular expression pattern.
+
+ This A pointer to the EFI_REGULAR_EXPRESSION_PROTOCOL instance.
+Type EFI_REGULAR_EXPRESSION_PROTOCOL is defined in Section
+XYZ.
+
+ StringA pointer to a NULL terminated string to match against the
+regular expression string specified
Re: [edk2] [PATCH] MdeModulePkg: Regular expression protocol
On 2015-05-27 13:45:45, El-Haj-Mahmoud, Samer wrote: Eric, I do not see how system firmware can reliably support multiple RegEx implementations using a single Regular_Expression_Protocol instance. That was definitely not the intention of, nor was it called for in the UEFI 2.5 specification. The library was just to allow someone to easily replace a single RegEx implementation with another. If that is not seen as important, we can easily drop the library, and keep a single driver implementation that produces a single instance of the protocol with a single RegEx implementation. Other drivers (most likely not in system firmware) can implement other flavors with new instances of Regular Expression Protocol. Does this sound reasonable? I think the library interface should closely match the protocol. (I think this differs from Eric's view?) If we closely match the protocol, then we can have a generic Dxe driver that layers on top of the library to produce the protocol. We can also have a 'helper' library implementation that layers upon the protocol. (The constructor locates the protocol and thereby makes it more convenient to use the protocol.) In other words, how about starting with something like this? EFI_STATUS EFIAPI ReGetLibInfo ( IN OUT UINTN*RegExSyntaxTypeListSize, OUTEFI_REGEX_SYNTAX_TYPE*RegExSyntaxTypeList ); EFI_STATUS EFIAPI ReMatchString ( IN CHAR16 *String, IN CHAR16 *Pattern, IN EFI_REGEX_SYNTAX_TYPE *SyntaxType, OPTIONAL OUT BOOLEAN *Result, OUT EFI_REGEX_CAPTURE **Captures, OPTIONAL OUT UINTN *CapturesCount ); -Jordan -Original Message- From: Dong, Eric [mailto:eric.d...@intel.com] Sent: Wednesday, May 27, 2015 12:05 AM To: El-Haj-Mahmoud, Samer; edk2-devel@lists.sourceforge.net; Doman, Jonathan Cc: Rothman, Michael A; Gao, Liming; Ni, Ruiyu Subject: RE: [edk2] [PATCH] MdeModulePkg: Regular expression protocol Samer Jonathan, Add my comments below. Thanks, Eric -Original Message- From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] Sent: Wednesday, May 27, 2015 4:39 AM To: edk2-devel@lists.sourceforge.net; Dong, Eric Subject: RE: [edk2] [PATCH] MdeModulePkg: Regular expression protocol Eric, The original design from UEFI 2.5 (as discussed in USWG) is to allow multiple implementations of the EFI_REGULAR_EXPRESSION_PROTOCOL by multiple drivers. This includes the ability for a UEFI driver, say from an IHV provided card firmware, extend the capabilities of the base driver supplied by the system firmware. That architecture (multiple RegEx protocols from different drivers) does not need the EDK2 router library design. The language in the UEFI spec (and the code in the HII Browser) is clearly expecting this design (looping through all RegEx protocol handles and trying them out one by one). [[[Eric]]] yes, agreed. I see that BIOS will provide only 1 RegEx implementation (there is REALLY no need for multiple implementations in BIOS). Other implementations can be provided by ISVs and IHVs by installing new instances of the RegEx protocol. [[[Eric]]] I don't know the direction now whether the bios need to support only one RegEx or more. If the bios only need to provide one RegEx implementation, I think we don't need the library, just add these code to the driver is enough. If we add the library to support later add more regex support, I think my design is more flexibility and has the capability add more regex support later. Hope this helps clarify the intention behind this implementation. Thanks, --Samer -Original Message- From: Doman, Jonathan Sent: Tuesday, May 26, 2015 12:41 PM To: Dong, Eric; edk2-devel@lists.sourceforge.net Subject: Re: [edk2] [PATCH] MdeModulePkg: Regular expression protocol I don't quite understand why the extra indirection layer is useful. The driver can be connected to a specific library B in the dsc file. If you later want to switch to a library C that provides more features, then update the dsc along with the syntax guids in the driver code. I think this is sufficient, and a little simpler, but I will consider your suggestion. [[[Eric]]] If follow your design, later when others provide another regex support, this design can't support both library at same time. Or it must copy all your code and add his new code to support more. But if follow my design, he just need to register his new regex(in library C) to library A and the system can support both library B and library C. It has the capability to accept more regex without change current code infrastructure. From: Dong, Eric [eric.d...@intel.com] Sent: Monday, May 25, 2015 03:21 To: edk2-devel@lists.sourceforge.net; Doman, Jonathan
Re: [edk2] [PATCH] MdeModulePkg: Regular expression protocol
On 2015-05-22 09:27:47, Doman, Jonathan wrote: Hi Ray, thanks for the feedback. 1. As you noticed, a valid handle is always returned whenever possible so that an error message can be retrieved. But this does complicate things, since RegExFree must then be called on all paths. I suppose a better solution might be to return a pointer to an error string directly from RegExCompile, and not create a handle upon failure. Since the protocol didn't define re compiles, should the library? I would say no. This actually seems like a pretty big issue with the protocol definition, but it is too late for discussing that. I think the library should be able to be implemented as a thin layer on top of the protocol. 2. No reason other than the fact that Unicode is not supported by any of our implementations. Does it match the spec then? I can change it to accept CHAR16 input strings. What do you think about the pattern itself? I don't see much use for CHAR16 patterns. Since the protoco defined it as CHAR16*, I think we'd need to support UTF-16 chars in the patterns. 3. We have many different use cases so the wrapper functions simplified things. If you only want to keep one, which is the most useful? I would like to keep CHAR16/CHAR8 (input/pattern) at least. I agree that the library could have Ascii wrappers to the unicode versions. -Jordan 4. Agreed. From: Ni, Ruiyu [ruiyu...@intel.com] Sent: Friday, May 22, 2015 01:15 To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] [PATCH] MdeModulePkg: Regular expression protocol 4. how about Regex instead of RegEx? C# uses Regex name. -Original Message- From: Ni, Ruiyu [mailto:ruiyu...@intel.com] Sent: Friday, May 22, 2015 1:29 PM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] [PATCH] MdeModulePkg: Regular expression protocol Doman, 1. If RegExCompile() returns ABORTED, is the HANDLE valid or not? Because of ABORTED, it makes more sense to let HANDLE to not be created. But then RegExErrorMessage(HANDLE) cannot be called. 2. Why do you use CHAR8 instead of CHAR16 for captured string? Even your library implementation just supports ASCII encoding, the interface should be able to accept CHAR16. 3. Why do you introduce different versions of RegExMatchStringXXX()? BaseLib contains UnicodeStrToAsciiStr()/AsciiStrToUnicodeStr() and caller can use them to do conversion before calling RegExMatchString(). I suggest we use CHAR16 and only accepts CHAR16. CHAR8 string needs be converted by caller before calling into RegEx library. Thanks, Ray -Original Message- From: Jonathan Doman [mailto:jonathan.do...@hp.com] Sent: Thursday, May 21, 2015 1:57 AM To: edk2-devel@lists.sourceforge.net Subject: [edk2] [PATCH] MdeModulePkg: Regular expression protocol Add RegularExpressionDxe driver. Add RegExLib library header and sample implementation SlreRegExLib, based on open-source SLRE library (old version with permissive license). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jonathan Doman jonathan.do...@hp.com --- MdeModulePkg/Include/Library/RegExLib.h| 165 + MdeModulePkg/Library/SlreRegExLib/SLRE/License.txt | 9 + .../Library/SlreRegExLib/SLRE/SlreUefiPort.h | 31 + MdeModulePkg/Library/SlreRegExLib/SLRE/slre.c | 684 + MdeModulePkg/Library/SlreRegExLib/SLRE/slre.h | 104 MdeModulePkg/Library/SlreRegExLib/SlreRegExLib.c | 301 + MdeModulePkg/Library/SlreRegExLib/SlreRegExLib.inf | 38 ++ MdeModulePkg/MdeModulePkg.dec | 3 + MdeModulePkg/MdeModulePkg.dsc | 2 + .../RegularExpressionDxe/RegularExpressionDxe.c| 306 + .../RegularExpressionDxe/RegularExpressionDxe.inf | 44 ++ 11 files changed, 1687 insertions(+) create mode 100644 MdeModulePkg/Include/Library/RegExLib.h create mode 100644 MdeModulePkg/Library/SlreRegExLib/SLRE/License.txt create mode 100644 MdeModulePkg/Library/SlreRegExLib/SLRE/SlreUefiPort.h create mode 100644 MdeModulePkg/Library/SlreRegExLib/SLRE/slre.c create mode 100644 MdeModulePkg/Library/SlreRegExLib/SLRE/slre.h create mode 100644 MdeModulePkg/Library/SlreRegExLib/SlreRegExLib.c create mode 100644 MdeModulePkg/Library/SlreRegExLib/SlreRegExLib.inf create mode 100644 MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c create mode 100644 MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf diff --git a/MdeModulePkg/Include/Library/RegExLib.h b/MdeModulePkg/Include/Library/RegExLib.h new file mode 100644 index 000..75c930d --- /dev/null +++ b/MdeModulePkg/Include/Library/RegExLib.h @@ -0,0 +1,165 @@ +/** @file + + Regular Expression Library Class + + Copyright (c) 2014-2015, Hewlett-Packard Development Company, L.P. + + This program and the accompanying materials are licensed
Re: [edk2] [PATCH v2] MdeModulePkg: Regular expression protocol
On 2015-05-26 08:22:22, Doman, Jonathan wrote: But regarding the protocol, EFI_REGULAR_EXPRESSION_PROTOCOL is already defined in MdePkg as part of UEFI 2.5 implementation. I think providing a sample implementation in MdeModulePkg is reasonable. Yep, you are right. I missed that one. I have a feeling implementing and using that protocol is going to be lots of fun. :) Side note, like MdePkg/Include/Protocol/Hash2.h, shouldn't MdePkg/Include/Protocol/RegularExpressionProtocol.h have a spec reference? -Jordan -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v2] MdeModulePkg: Regular expression protocol
On 2015-05-20 14:08:40, Jonathan Doman wrote:
Add RegularExpressionDxe driver. Add RegExLib library header and sample
implementation SlreRegExLib, based on open-source SLRE library (old
version with permissive license).
I think you should mention THE BEER-WARE LICENSE (Revision 42) here.
But, rather, how about trying instead to port this 2-clause BSD code?
https://github.com/laurikari/tre/
I also wonder if this belongs in MdeModulePkg. Also, is a protocol
appropriate? I guess if you are using it in various drivers in the
firmware.
I'm thinking this might be more valuable for applications, and thus
I'm wondering if just a library interface and implementation in AppPkg
might something to start with.
Regarding the commits, I think they should be split:
1. Library interface
2. Protocol interface
3. Library implementation
4. Dxe driver
-Jordan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jonathan Doman jonathan.do...@hp.com
---
v2 changes:
* Fix use of variadic macro and strchr define
MdeModulePkg/Include/Library/RegExLib.h| 165 +
MdeModulePkg/Library/SlreRegExLib/SLRE/License.txt | 9 +
.../Library/SlreRegExLib/SLRE/SlreUefiPort.h | 31 +
MdeModulePkg/Library/SlreRegExLib/SLRE/slre.c | 684
+
MdeModulePkg/Library/SlreRegExLib/SLRE/slre.h | 104
MdeModulePkg/Library/SlreRegExLib/SlreRegExLib.c | 301 +
MdeModulePkg/Library/SlreRegExLib/SlreRegExLib.inf | 38 ++
MdeModulePkg/MdeModulePkg.dec | 3 +
MdeModulePkg/MdeModulePkg.dsc | 2 +
.../RegularExpressionDxe/RegularExpressionDxe.c| 306 +
.../RegularExpressionDxe/RegularExpressionDxe.inf | 44 ++
11 files changed, 1687 insertions(+)
create mode 100644 MdeModulePkg/Include/Library/RegExLib.h
create mode 100644 MdeModulePkg/Library/SlreRegExLib/SLRE/License.txt
create mode 100644 MdeModulePkg/Library/SlreRegExLib/SLRE/SlreUefiPort.h
create mode 100644 MdeModulePkg/Library/SlreRegExLib/SLRE/slre.c
create mode 100644 MdeModulePkg/Library/SlreRegExLib/SLRE/slre.h
create mode 100644 MdeModulePkg/Library/SlreRegExLib/SlreRegExLib.c
create mode 100644 MdeModulePkg/Library/SlreRegExLib/SlreRegExLib.inf
create mode 100644
MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
create mode 100644
MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
diff --git a/MdeModulePkg/Include/Library/RegExLib.h
b/MdeModulePkg/Include/Library/RegExLib.h
new file mode 100644
index 000..75c930d
--- /dev/null
+++ b/MdeModulePkg/Include/Library/RegExLib.h
@@ -0,0 +1,165 @@
+/** @file
+
+ Regular Expression Library Class
+
+ Copyright (c) 2014-2015, Hewlett-Packard Development Company, L.P.
+
+ This program and the accompanying materials are licensed and made available
+ under the terms and conditions of the BSD License that accompanies this
+ distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php.
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
WITHOUT
+ WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+#ifndef REG_EX_LIB_H
+#define REG_EX_LIB_H
+
+#include Uefi.h
+
+typedef VOID* REG_EX_HANDLE;
+
+/**
+ Container for returning information about subexpression captures resulting
+ from successful matches.
+**/
+typedef struct {
+ CONST CHAR8 *Ptr; /// Beginning of captured subexpression within
matched string.
+ INT32 Length; /// Length of captured subexpression.
+} REG_EX_CAPTURE;
+
+/**
+ Compile a regular expression in preparation for matching with RegExMatch.
+ A call to RegExFree is always required to free resources regardless of
+ whether compilation was successful.
+
+ @param[out] HandlePointer to RegExHandle to initialize. Must be freed
+ with a call to RegExFree when no longer needed.
+ @param[in]Pattern Pointer to null-terminated ASCII string containing
+ the desired regular expression.
+
+ @return EFI_SUCCESS Operation was successful.
+EFI_ABORTED Pattern could not be compiled. More
information
+may be found through RegExErrorMessage.
+EFI_INVALID_PARAMETER A required parameter was NULL.
+EFI_OUT_OF_RESOURCESMemory allocation failed.
+**/
+EFI_STATUS
+EFIAPI
+RegExCompile (
+ OUT REG_EX_HANDLE *Handle,
+ IN CONST CHAR8 *Pattern
+ );
+
+/**
+ Search the input string for anything that matches the regular expression.
+
+ Be aware that the specific implementation of this library class may not
+ support all regular expression syntax, which could lead to unexpected
results.
+
+ If no match is found, the contents of Captures is undefined (i.e. it may be
+
