Re: [edk2] [PATCH 0/5] OvmfPkg/QemuVideoDxe: cleanups and tweaks

[Jordan Justen]

Series Reviewed-by: Jordan Justen 

On 2016-10-12 03:09:00, Laszlo Ersek wrote:
> Reviewing (part of) Ray's recent FrameBufferBltLib changes gave me the
> idea for this. The patches are really small.
> 
> Public branch: .
> 
> Cc: Jordan Justen 
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (5):
>   OvmfPkg/QemuVideoDxe: drop useless QEMU_VIDEO_MODE_DATA.RefreshRate
>   OvmfPkg/QemuVideoDxe: drop QEMU_VIDEO_CIRRUS_MODES.RefreshRate
>   OvmfPkg/QemuVideoDxe: remove useless
> QEMU_VIDEO_PRIVATE_DATA.CurrentMode
>   OvmfPkg/QemuVideoDxe: remove useless
> QEMU_VIDEO_PRIVATE_DATA.LineBuffer
>   OvmfPkg/QemuVideoDxe: upgrade VERBOSE debug messages to INFO
> 
>  OvmfPkg/QemuVideoDxe/Qemu.h   |  9 ++
>  OvmfPkg/QemuVideoDxe/Gop.c| 16 ---
>  OvmfPkg/QemuVideoDxe/Initialize.c | 30 +---
>  OvmfPkg/QemuVideoDxe/VbeShim.c|  4 +--
>  4 files changed, 17 insertions(+), 42 deletions(-)
> 
> -- 
> 2.9.2
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: PatchCheck to align with wiki and report error for EFI_D_*

[Jordan Justen]

On 2016-10-13 02:29:46, Yonghong Zhu wrote:
> This patch updates PatchCheck.py：

Can you split this into 3 separate patches?

> 1.Update max line length to 70 that describe in wiki

I think we should update PatchCheck.py and the wiki to say that:

1. The subject line of the commit message should be < 72 characters.

This works well with git log --oneline to still produce output less
than 80 characters.

2. The other lines of the commit message should be < 76 characters.

When using git log, these lines are indented 4 characters, so once
again this will keep the log message readable and under 80 columns.

> 2.remove the two [] when do the char count calculation

How about instead we add a new regex to the class:

subject_prefix_re = \
re.compile(r'''^
   \s* (\[
   [^\[\]]* # Allow all non-brackets
   \])? \s*
   ''',
   re.VERBOSE)


Then you can use it line this:

  self.commit_subject = \
  self.subject_prefix_re.sub('', self.commit_subject, 1)

This will change:

  ' a' => 'a'
  ' [patch 1] a' => 'a'

But, it will ignore this, because I don't think we should try to match
brackets here:

  ' [a [b]] a'

> 3.report error for EFI_D_* macro if it is used, recommend to use
> DEBUG_* format.

This should definitely be a separate patch since we are starting to
look at code.

-Jordan

> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Scripts/PatchCheck.py | 21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/BaseTools/Scripts/PatchCheck.py b/BaseTools/Scripts/PatchCheck.py
> index 455c130..d423220 100755
> --- a/BaseTools/Scripts/PatchCheck.py
> +++ b/BaseTools/Scripts/PatchCheck.py
> @@ -1,9 +1,9 @@
>  ## @file
>  #  Check a patch for various format issues
>  #
> -#  Copyright (c) 2015, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
>  #
>  #  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
> @@ -14,11 +14,11 @@
>  #
>  
>  from __future__ import print_function
>  
>  VersionNumber = '0.1'
> -__copyright__ = "Copyright (c) 2015, Intel Corporation  All rights reserved."
> +__copyright__ = "Copyright (c) 2015 - 2016, Intel Corporation  All rights 
> reserved."
>  
>  import email
>  import argparse
>  import os
>  import re
> @@ -195,11 +195,11 @@ class CommitMessageCheck:
>  
>  if count <= 0:
>  self.error('Empty commit message!')
>  return
>  
> -if count >= 1 and len(lines[0]) > 76:
> +if count >= 1 and len(lines[0]) > 70:
>  self.error('First line of commit message (subject line) ' +
> 'is too long.')
>  
>  if count >= 1 and len(lines[0].strip()) == 0:
>  self.error('First line of commit message (subject line) ' +
> @@ -208,11 +208,11 @@ class CommitMessageCheck:
>  if count >= 2 and lines[1].strip() != '':
>  self.error('Second line of commit message should be ' +
> 'empty.')
>  
>  for i in range(2, count):
> -if (len(lines[i]) > 76 and
> +if (len(lines[i]) > 70 and
>  len(lines[i].split()) > 1 and
>  not lines[i].startswith('git-svn-id:')):
>  self.error('Line %d of commit message is too long.' % (i + 
> 1))
>  
>  last_sig_line = None
> @@ -354,10 +354,12 @@ class GitDiffCheck:
>line)
>  if '' in line:
>  self.added_line_error('Tab character used', line)
>  if len(stripped) < len(line):
>  self.added_line_error('Trailing whitespace found', line)
> +if 'EFI_D_' in line:
> +self.added_line_error('EFI_D_* used, Please use DEBUG_* format', 
> line)
>  
>  split_diff_re = re.compile(r'''
> (?P
> ^ diff \s+ --git \s+ a/.+ \s+ b/.+ $
> )
> @@ -471,11 +473,20 @@ class CheckOnePatch:
>  self.commit_msg = mo.group('commit_message')
>  
>  self.commit_subject = pmail['subject'].replace('\r\n', '')
>  self.commit_subject = self.commit_subject.replace('\n', '')
>  
> -pfx_start = self.commit_subject.find('[')
> +pfx_start_tmp = self.commit_subject.find('[')
> +pfx_end = self.commit_subject.find(']', pfx_start_tmp)
> +pfx_start = pfx_start_tmp
> +while (pfx_end > pfx_start_tmp):
> +pfx_start_tmp = 

Re: [edk2] [PATCH] ArmVirtPkg: undo bogus component name and driver diagnostics disablement

[Laszlo Ersek]

On 10/15/16 18:58, Ard Biesheuvel wrote:
> On 15 October 2016 at 17:56, Laszlo Ersek  wrote:
>> The entry point function of any UEFI_DRIVER that conforms to the UEFI
>> driver model must install an instance of the EFI_DRIVER_BINDING_PROTOCOL
>> on the image handle. Beyond that, the following protocols are optional:
>>
>> - EFI_COMPONENT_NAME_PROTOCOL
>> - EFI_COMPONENT_NAME2_PROTOCOL
>> - EFI_DRIVER_CONFIGURATION_PROTOCOL
>> - EFI_DRIVER_CONFIGURATION2_PROTOCOL
>> - EFI_DRIVER_DIAGNOSTICS_PROTOCOL
>> - EFI_DRIVER_DIAGNOSTICS2_PROTOCOL
>>
>> The UefiLib functions
>>
>> - EfiLibInstallAllDriverProtocols()
>> - EfiLibInstallAllDriverProtocols2()
>> - EfiLibInstallDriverBindingComponentName2()
>>
>> are convenience helpers for such UEFI_DRIVERs. They simplify the
>> installation of the above protocols.
>>
>> The UefiLib instance in "MdePkg/Library/UefiLib/UefiDriverModel.c" allows
>> platforms to control these functions through the MdePkg feature PCDs
>>
>> - PcdComponentNameDisable
>> - PcdComponentName2Disable
>> - PcdDriverDiagnosticsDisable
>> - PcdDriverDiagnostics2Disable
>>
>> If any of these PCDs are set to TRUE, then the helper functions will not
>> install the corresponding protocol interfaces on the image handle, even if
>> the driver passes in non-NULL protocol interfaces.
>>
>> In other words, at build time, a platform can forcibly prevent all drivers
>> that employ UefiLib from producing these protocols.
>>
>> In ArmVirtPkg, that's what we've been doing forever, for no reason at all.
>> This is why we haven't been seeing component and driver names from the DH,
>> DEVICES, DRIVERS and DEVTREE shell commands, unlike in OvmfPkg.
>>
>> The default value for all these PCDs is FALSE, in "MdePkg/MdePkg.dec".
>> Revert ArmVirtPkg to the sane defaults.
>>
>> This bug dates back to the inception of ArmVirtPkg (called
>> ArmPlatformPkg/ArmVirtualizationPkg at the time).
>>
>> Cc: Ard Biesheuvel 
>> Fixes: 6f5872b1f4013f58c6d2f446d885edd6c8ea6d21
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
> 
> Reviewed-by: Ard Biesheuvel 

Commit 5b54c92a6537.

> I always had a suspicion we were missing something here, but I never
> got around to tracking it down. Thanks for doing that.

It's Saturday evening after all, i.e., when I'm supposed to have fun ;)

Thanks!
Laszlo

>> ---
>>  ArmVirtPkg/ArmVirt.dsc.inc | 4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
>> index c624b3cdbecd..c071988ad8f5 100644
>> --- a/ArmVirtPkg/ArmVirt.dsc.inc
>> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
>> @@ -254,10 +254,6 @@ [BuildOptions]
>>
>>  [PcdsFeatureFlag.common]
>>gEfiMdeModulePkgTokenSpaceGuid.PcdHiiOsRuntimeSupport|FALSE
>> -  gEfiMdePkgTokenSpaceGuid.PcdComponentNameDisable|TRUE
>> -  gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnosticsDisable|TRUE
>> -  gEfiMdePkgTokenSpaceGuid.PcdComponentName2Disable|TRUE
>> -  gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnostics2Disable|TRUE
>>
>>#
>># Control what commands are supported from the UI
>> --
>> 2.9.2
>>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmVirtPkg: undo bogus component name and driver diagnostics disablement

[Ard Biesheuvel]

On 15 October 2016 at 17:56, Laszlo Ersek  wrote:
> The entry point function of any UEFI_DRIVER that conforms to the UEFI
> driver model must install an instance of the EFI_DRIVER_BINDING_PROTOCOL
> on the image handle. Beyond that, the following protocols are optional:
>
> - EFI_COMPONENT_NAME_PROTOCOL
> - EFI_COMPONENT_NAME2_PROTOCOL
> - EFI_DRIVER_CONFIGURATION_PROTOCOL
> - EFI_DRIVER_CONFIGURATION2_PROTOCOL
> - EFI_DRIVER_DIAGNOSTICS_PROTOCOL
> - EFI_DRIVER_DIAGNOSTICS2_PROTOCOL
>
> The UefiLib functions
>
> - EfiLibInstallAllDriverProtocols()
> - EfiLibInstallAllDriverProtocols2()
> - EfiLibInstallDriverBindingComponentName2()
>
> are convenience helpers for such UEFI_DRIVERs. They simplify the
> installation of the above protocols.
>
> The UefiLib instance in "MdePkg/Library/UefiLib/UefiDriverModel.c" allows
> platforms to control these functions through the MdePkg feature PCDs
>
> - PcdComponentNameDisable
> - PcdComponentName2Disable
> - PcdDriverDiagnosticsDisable
> - PcdDriverDiagnostics2Disable
>
> If any of these PCDs are set to TRUE, then the helper functions will not
> install the corresponding protocol interfaces on the image handle, even if
> the driver passes in non-NULL protocol interfaces.
>
> In other words, at build time, a platform can forcibly prevent all drivers
> that employ UefiLib from producing these protocols.
>
> In ArmVirtPkg, that's what we've been doing forever, for no reason at all.
> This is why we haven't been seeing component and driver names from the DH,
> DEVICES, DRIVERS and DEVTREE shell commands, unlike in OvmfPkg.
>
> The default value for all these PCDs is FALSE, in "MdePkg/MdePkg.dec".
> Revert ArmVirtPkg to the sane defaults.
>
> This bug dates back to the inception of ArmVirtPkg (called
> ArmPlatformPkg/ArmVirtualizationPkg at the time).
>
> Cc: Ard Biesheuvel 
> Fixes: 6f5872b1f4013f58c6d2f446d885edd6c8ea6d21
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

I always had a suspicion we were missing something here, but I never
got around to tracking it down. Thanks for doing that.

> ---
>  ArmVirtPkg/ArmVirt.dsc.inc | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index c624b3cdbecd..c071988ad8f5 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -254,10 +254,6 @@ [BuildOptions]
>
>  [PcdsFeatureFlag.common]
>gEfiMdeModulePkgTokenSpaceGuid.PcdHiiOsRuntimeSupport|FALSE
> -  gEfiMdePkgTokenSpaceGuid.PcdComponentNameDisable|TRUE
> -  gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnosticsDisable|TRUE
> -  gEfiMdePkgTokenSpaceGuid.PcdComponentName2Disable|TRUE
> -  gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnostics2Disable|TRUE
>
>#
># Control what commands are supported from the UI
> --
> 2.9.2
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ArmVirtPkg: undo bogus component name and driver diagnostics disablement

[Laszlo Ersek]

The entry point function of any UEFI_DRIVER that conforms to the UEFI
driver model must install an instance of the EFI_DRIVER_BINDING_PROTOCOL
on the image handle. Beyond that, the following protocols are optional:

- EFI_COMPONENT_NAME_PROTOCOL
- EFI_COMPONENT_NAME2_PROTOCOL
- EFI_DRIVER_CONFIGURATION_PROTOCOL
- EFI_DRIVER_CONFIGURATION2_PROTOCOL
- EFI_DRIVER_DIAGNOSTICS_PROTOCOL
- EFI_DRIVER_DIAGNOSTICS2_PROTOCOL

The UefiLib functions

- EfiLibInstallAllDriverProtocols()
- EfiLibInstallAllDriverProtocols2()
- EfiLibInstallDriverBindingComponentName2()

are convenience helpers for such UEFI_DRIVERs. They simplify the
installation of the above protocols.

The UefiLib instance in "MdePkg/Library/UefiLib/UefiDriverModel.c" allows
platforms to control these functions through the MdePkg feature PCDs

- PcdComponentNameDisable
- PcdComponentName2Disable
- PcdDriverDiagnosticsDisable
- PcdDriverDiagnostics2Disable

If any of these PCDs are set to TRUE, then the helper functions will not
install the corresponding protocol interfaces on the image handle, even if
the driver passes in non-NULL protocol interfaces.

In other words, at build time, a platform can forcibly prevent all drivers
that employ UefiLib from producing these protocols.

In ArmVirtPkg, that's what we've been doing forever, for no reason at all.
This is why we haven't been seeing component and driver names from the DH,
DEVICES, DRIVERS and DEVTREE shell commands, unlike in OvmfPkg.

The default value for all these PCDs is FALSE, in "MdePkg/MdePkg.dec".
Revert ArmVirtPkg to the sane defaults.

This bug dates back to the inception of ArmVirtPkg (called
ArmPlatformPkg/ArmVirtualizationPkg at the time).

Cc: Ard Biesheuvel 
Fixes: 6f5872b1f4013f58c6d2f446d885edd6c8ea6d21
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 ArmVirtPkg/ArmVirt.dsc.inc | 4 
 1 file changed, 4 deletions(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index c624b3cdbecd..c071988ad8f5 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -254,10 +254,6 @@ [BuildOptions]
 
 [PcdsFeatureFlag.common]
   gEfiMdeModulePkgTokenSpaceGuid.PcdHiiOsRuntimeSupport|FALSE
-  gEfiMdePkgTokenSpaceGuid.PcdComponentNameDisable|TRUE
-  gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnosticsDisable|TRUE
-  gEfiMdePkgTokenSpaceGuid.PcdComponentName2Disable|TRUE
-  gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnostics2Disable|TRUE
 
   #
   # Control what commands are supported from the UI
-- 
2.9.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Trying to build an uefi application that is out of UDK directory

[Denis Alberto Silverio]

Hi guys
I've created an uefi application in a directory that is not inside the
EDK2015 folder.
For example:

My UDK folder is:
C:\Projects\UEFI\UDK2015_r18552
|- BaseTools
|- Conf
|- CryptoPkg
|-etc

My Uefi app is on:
C:\Projects\UEFI\Projects\MyApp
|- EntryPoint.c
|- MyApp.dsc
|- .etc

I´ve done the whole UDK2015 build proccess and now i'am trying to build my
application
So, to build my app i'm running these commands on an Windows cmd:

cd C:\Projects\UEFI\UDK2015_r18552
edksetup.bat --NT32
cd C:\Projects\UEFI\Projects\MyApp
build -p C:\Projects\UEFI\Projects\MaApp\MyApp.dsc -m
C:\Projects\UEFI\Projects\MyApp\MyApp.inf -a X64 -t VS2013x86 -D
PROJECT_DIRECTORY_NAME=C:\Projects\UEFI\Projects\MyApp

and this error appears..
>>
(Please send email to edk2-devel@"lists.sourceforge.net for help, attaching
following call stack trace!)

(Python 2.7.3 on win32) Traceback (most recent call last):
  File "build.py", line 2033, in Main
  File "build.py", line 1792, in Launch
  File "build.py", line 1509, in _BuildModule
  File "build.py", line 1032, in _Build
  File
"c:\Users\Public\Documents\BuildPool\BaseTools\build\Source\Python\AutoGen\AutoGen.py",
line 3517, in CreateMakeF
ile
  File
"c:\Users\Public\Documents\BuildPool\BaseTools\build\Source\Python\AutoGen\AutoGen.py",
line 3523, in CreateMakeF
ile
  File
"c:\Users\Public\Documents\BuildPool\BaseTools\build\Source\Python\AutoGen\GenMake.py",
line 184, in Generate
  File
"c:\Users\Public\Documents\BuildPool\BaseTools\build\Source\Python\AutoGen\GenMake.py",
line 563, in _CreateTempl
ateDict
  File
"c:\Users\Public\Documents\BuildPool\BaseTools\build\Source\Python\Common\LongFilePathOs.py",
line 56, in listdir

WindowsError: [Error 123] The filename, directory name, or volume label
syntax is incorrect: u'?\\c:\\projects\\uefi
\\udk2015_r18552\\C:*.*'
<<

To resolve this problem, I created a symbolic link on UDK2015 folder to
linking myApp folder and apparently it works.
Is there another way to build an application that is out of UDK folder?

Thank you!
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg

[Yao, Jiewen]

Of course, it is fine to give a good name in MdePkg. :)

My concern is only about "Compatibility".
This series patch only updated ArmPkg and EmbeddedPkg.
But there might be more close source IP protected packages using the original 
header file.

That is why I propose a compatible way: We give a good file name in MdePkg. At 
same time, we can keep the old file name in ShellPkg to include the good name 
in MdePkg.

I recommend we give a solution to make close source package unchanged after 
this patch is applied.

Thank you
Yao Jiewen


From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Saturday, October 15, 2016 12:21 AM
To: Yao, Jiewen ; Ni, Ruiyu ; 
edk2-devel@lists.01.org
Subject: RE: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg

I prefer the renamed .h file, even though I have substantial investment in the 
current infrastructure.

Why? Because engineers don't have time to remember "how does protocol X 
translate to header file Y" It should be a consistent rule. How many times have 
I needed to grep the header file name just because I got a build error because 
the rule wasn't predictable.

1) remove the EFI_ prefix and the _PROTOCOL  suffix (EFI_BLOCK_IO_PROTOCOL -> 
BLOCK_IO
2) Convert to upper-and-lower case, BLOCK_IO -> Block_Io
3) Remove the _ (Block_Io -> BlockIo)
4)  add a .h BlockIo -> BlockIo.h

Most protocol and PPI header files already follow this rule. The current header 
files for shell are among the few exceptions, because they don't follow this.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
Jiewen
Sent: Friday, October 14, 2016 6:14 AM
To: Yao, Jiewen >; Ni, Ruiyu 
>; 
edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg

Or if you really think we should give a better name.

My recommendation is:

1)  We add content in MdePkg.

2)  We can keep the old protocol file in ShellPkg, but let .h in shellPkg 
include the .h in MdePkg.

Then we can avoid duplicated code and make it a compatible solution to avoid 
other module update.

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
Jiewen
Sent: Friday, October 14, 2016 9:09 PM
To: Ni, Ruiyu >; 
edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg

Hi
I think the requests is just to *move*.

There is no request to *rename*.

Can we just move to avoid other update?


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ruiyu Ni
> Sent: Friday, October 14, 2016 5:44 PM
> To: 
> edk2-devel@lists.01.org>
> Subject: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg
>
> The patches moves Shell spec defined protocol definitions to MdePkg
> and updates all references.
> Content of ShellBase.h is moved to Protocol/Shell.h and ShellBase.h is
> removed.
>
> Ruiyu Ni (5):
>   ShellPkg: Move SHELL_FREE_NON_NULL from ShellBase.h to ShellLib.h
>   MdePkg: Include Shell/ShellDynamicCommand/ShellParameters
> definitions
>   ArmPkg/LinuxLoader: Reference Shell protocols in MdePkg
>   EmbeddedPkg/FdtPlatformDxe: Reference Shell protocols in MdePkg
>   ShellPkg: Remove Shell/ShellDynamicCommand/ShellParameter
> definitions
>
>  ArmPkg/Application/LinuxLoader/LinuxLoader.h   |   4 +-
>  EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h   |   4 +-
>  .../EfiShell.h => MdePkg/Include/Protocol/Shell.h  | 134
> +-
>  .../Include/Protocol/ShellDynamicCommand.h |   7 +-
>  .../Include/Protocol/ShellParameters.h |   4 +-
>  MdePkg/MdePkg.dec  |  15 ++
>  ShellPkg/Application/Shell/Shell.h |   5 +-
>  ShellPkg/Include/Library/ShellCommandLib.h |   5 +-
>  ShellPkg/Include/Library/ShellLib.h|  14 +-
>  ShellPkg/Include/ShellBase.h   | 157
> -
>  ShellPkg/Library/UefiDpLib/Dp.h|   3 +-
>  ShellPkg/Library/UefiDpLib/UefiDpLib.h |   7 +-
>  .../UefiHandleParsingLib/UefiHandleParsingLib.h|   8 +-
>  .../UefiShellBcfgCommandLib.c  |   5 +-
>  .../UefiShellCEntryLib/UefiShellCEntryLib.c|   6 +-
>  .../UefiShellCommandLib/UefiShellCommandLib.h  |   7 +-
>  .../Library/UefiShellDebug1CommandsLib/Compress.c  |   7 +-
>  .../UefiShellDebug1CommandsLib.h   |   7 +-
>  .../UefiShellDriver1CommandsLib.h  |   7 +-
>  .../UefiShellLevel1CommandsLib.h   |   7 +-
>  .../UefiShellLevel2CommandsLib.h