2010-09-14 05:18:09 +00:00
|
|
|
/** @file
|
|
|
|
|
Provides interface to shell internal functions for shell commands.
|
|
|
|
|
|
2018-01-26 16:41:37 +08:00
|
|
|
Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved. <BR>
|
2016-07-28 16:31:57 +08:00
|
|
|
(C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
|
2019-04-03 16:07:06 -07:00
|
|
|
SPDX-License-Identifier: BSD-2-Clause-Patent
|
2010-09-14 05:18:09 +00:00
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
|
ShellPkg: Replace include guards with #pragma once
Replace traditional `#ifndef`/`#define`/`#endif` include guards with
`#pragma` once.
`#pragma once` is a widely supported preprocessor directive that
prevents header files from being included multiple times. It is
supported by all toolchains used to build edk2: GCC, Clang/LLVM, and
MSVC.
Compared to macro-based include guards, `#pragma once`:
- Eliminates the risk of macro name collisions or copy/paste errors
where two headers inadvertently use the same guard macro.
- Eliminate inconsistency in the way include guard macros are named
(e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.).
- Reduces boilerplate (three lines replaced by one).
- Avoids polluting the macro namespace with guard symbols.
- Can improve build times as the preprocessor can skip re-opening the
file entirely, rather than re-reading it to find the matching
`#endif` ("multiple-include optimization").
- Note that some compilers may already optimize traditional include
guards, by recognzining the idiomatic pattern.
This change is made acknowledging that overall portability of the
code will technically be reduced, as `#pragma once` is not part of the
C/C++ standards.
However, this is considered acceptable given:
1. edk2 already defines a subset of supported compilers in
BaseTools/Conf/tools_def.template, all of which have supported
`#pragma once` for over two decades.
2. There have been concerns raised to the project about inconsistent
include guard naming and potential macro collisions.
Approximate compiler support dates:
- MSVC: Supported since Visual C++ 4.2 (1996)
- GCC: Supported since 3.4 (2004)
(http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html)
- Clang (LLVM based): Since initial release in 2007
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
2026-02-03 14:26:33 -05:00
|
|
|
#pragma once
|
2010-09-14 05:18:09 +00:00
|
|
|
|
|
|
|
|
#include <Uefi.h>
|
|
|
|
|
|
|
|
|
|
#include <Guid/FileInfo.h>
|
2018-01-26 16:41:37 +08:00
|
|
|
#include <Guid/GlobalVariable.h>
|
2010-09-14 05:18:09 +00:00
|
|
|
|
|
|
|
|
#include <Protocol/SimpleFileSystem.h>
|
|
|
|
|
#include <Protocol/LoadedImage.h>
|
|
|
|
|
#include <Protocol/EfiShellInterface.h>
|
|
|
|
|
#include <Protocol/EfiShellEnvironment2.h>
|
2016-10-18 14:30:42 +08:00
|
|
|
#include <Protocol/Shell.h>
|
|
|
|
|
#include <Protocol/ShellParameters.h>
|
2010-09-14 05:18:09 +00:00
|
|
|
#include <Protocol/UnicodeCollation.h>
|
|
|
|
|
#include <Protocol/BlockIo.h>
|
2016-10-18 14:30:42 +08:00
|
|
|
#include <Protocol/ShellDynamicCommand.h>
|
2010-09-14 05:18:09 +00:00
|
|
|
|
|
|
|
|
#include <Library/DevicePathLib.h>
|
|
|
|
|
#include <Library/SortLib.h>
|
|
|
|
|
#include <Library/HandleParsingLib.h>
|
|
|
|
|
#include <Library/BaseLib.h>
|
|
|
|
|
#include <Library/BaseMemoryLib.h>
|
|
|
|
|
#include <Library/DebugLib.h>
|
|
|
|
|
#include <Library/MemoryAllocationLib.h>
|
|
|
|
|
#include <Library/PcdLib.h>
|
2010-09-17 20:08:20 +00:00
|
|
|
#include <Library/ShellCommandLib.h>
|
2010-09-14 05:18:09 +00:00
|
|
|
#include <Library/PrintLib.h>
|
|
|
|
|
#include <Library/ShellLib.h>
|
|
|
|
|
#include <Library/HiiLib.h>
|
|
|
|
|
#include <Library/UefiBootServicesTableLib.h>
|
2016-07-28 16:31:57 +08:00
|
|
|
#include <Library/UefiLib.h>
|
ShellPkg/ShellCommandLib: add ShellSortFileList()
Introduce the ShellSortFileList() function, for sorting an
EFI_SHELL_FILE_INFO list, by FileName or by FullName.
Duplicates can be kept in the same list, or separated out to a new list.
In either case, the relative order between duplicates does not change (the
sorting is stable).
For the sorting, use OrderedCollectionLib rather than SortLib:
- The PerformQuickSort() function from the latter has quadratic worst-case
time complexity, plus it is implemented recursively (see
"MdeModulePkg/Library/UefiSortLib/UefiSortLib.c"). It can also not
return an error on memory allocation failure.
- In comparison, the Red-Black Tree instance of OrderedCollectionLib sorts
in O(n*log(n)) worst-case time, contains no recursion with the default
PcdValidateOrderedCollection=FALSE setting, and the OrderedCollectionLib
class APIs return errors appropriately.
The OrderedCollectionLib APIs do not permit duplicates natively, but by
using lists as collection entries, stable sorting of duplicates can be
achieved.
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3151
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Message-Id: <20210113085453.10168-7-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-01-13 09:54:49 +01:00
|
|
|
#include <Library/OrderedCollectionLib.h>
|
2010-09-14 05:18:09 +00:00
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
LIST_ENTRY Link;
|
|
|
|
|
CHAR16 *CommandString;
|
|
|
|
|
SHELL_GET_MAN_FILENAME GetManFileName;
|
|
|
|
|
SHELL_RUN_COMMAND CommandHandler;
|
|
|
|
|
BOOLEAN LastError;
|
ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE
The UefiShell*CommandsLib instances have constructor functions that do
something like:
gHiiHandle = HiiAddPackages (...);
...
ShellCommandRegisterCommandName (..., gHiiHandle, ...);
and destructor functions that implement the following pattern:
HiiRemovePackages (gHiiHandle);
The -- semantic, not functional -- problem is that "gHiiHandle" is
declared with type EFI_HANDLE, and not EFI_HII_HANDLE, in all of these
library instances, even though HiiAddPackages() correctly returns
EFI_HII_HANDLE, and HiiRemovePackages() takes EFI_HII_HANDLE.
Once we fix the type of "gHiiHandle", it causes sort of a butterfly
effect, because it is passed around widely. Track down and update all of
those locations.
The DynamicCommand lib instances use a similar pattern, so they are
affected too.
NOTE: in practice, this patch is a no-op, as both EFI_HII_HANDLE and
EFI_HANDLE are typedefs to (VOID*). However, we shouldn't use EFI_HANDLE
where semantically EFI_HII_HANDLE is passed around.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
2019-09-06 23:15:42 +02:00
|
|
|
EFI_HII_HANDLE HiiHandle;
|
2010-09-14 05:18:09 +00:00
|
|
|
EFI_STRING_ID ManFormatHelp;
|
|
|
|
|
} SHELL_COMMAND_INTERNAL_LIST_ENTRY;
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
LIST_ENTRY Link;
|
|
|
|
|
SCRIPT_FILE *Data;
|
|
|
|
|
} SCRIPT_FILE_LIST;
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
EFI_FILE_PROTOCOL *FileHandle;
|
|
|
|
|
CHAR16 *Path;
|
|
|
|
|
} SHELL_COMMAND_FILE_HANDLE;
|
|
|
|
|
|
ShellPkg/ShellCommandLib: add ShellSortFileList()
Introduce the ShellSortFileList() function, for sorting an
EFI_SHELL_FILE_INFO list, by FileName or by FullName.
Duplicates can be kept in the same list, or separated out to a new list.
In either case, the relative order between duplicates does not change (the
sorting is stable).
For the sorting, use OrderedCollectionLib rather than SortLib:
- The PerformQuickSort() function from the latter has quadratic worst-case
time complexity, plus it is implemented recursively (see
"MdeModulePkg/Library/UefiSortLib/UefiSortLib.c"). It can also not
return an error on memory allocation failure.
- In comparison, the Red-Black Tree instance of OrderedCollectionLib sorts
in O(n*log(n)) worst-case time, contains no recursion with the default
PcdValidateOrderedCollection=FALSE setting, and the OrderedCollectionLib
class APIs return errors appropriately.
The OrderedCollectionLib APIs do not permit duplicates natively, but by
using lists as collection entries, stable sorting of duplicates can be
achieved.
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3151
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Message-Id: <20210113085453.10168-7-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-01-13 09:54:49 +01:00
|
|
|
//
|
|
|
|
|
// Collects multiple EFI_SHELL_FILE_INFO objects that share the same name.
|
|
|
|
|
//
|
|
|
|
|
typedef struct {
|
|
|
|
|
//
|
|
|
|
|
// A string that compares equal to either the FileName or the FullName fields
|
|
|
|
|
// of all EFI_SHELL_FILE_INFO objects on SameNameList, according to
|
|
|
|
|
// gUnicodeCollation->StriColl(). The string is not dynamically allocated;
|
|
|
|
|
// instead, it *aliases* the FileName or FullName field of the
|
|
|
|
|
// EFI_SHELL_FILE_INFO object that was first encountered with this name.
|
|
|
|
|
//
|
|
|
|
|
CONST CHAR16 *Alias;
|
|
|
|
|
//
|
|
|
|
|
// A list of EFI_SHELL_FILE_INFO objects whose FileName or FullName fields
|
|
|
|
|
// compare equal to Alias, according to gUnicodeCollation->StriColl().
|
|
|
|
|
//
|
|
|
|
|
LIST_ENTRY SameNameList;
|
|
|
|
|
} SHELL_SORT_UNIQUE_NAME;
|