Commit Graph

6 Commits

Author SHA1 Message Date
Rebecca Cran 8ba392687b OvmfPkg: Update code to be more C11 compliant by using __func__
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.

Since it's more standard, replace __FUNCTION__ with __func__ throughout
OvmfPkg.

Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
2023-04-10 14:19:57 +00:00
Michael Kubacki ac0a286f4d OvmfPkg: Apply uncrustify changes
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737

Apply uncrustify changes to .c/.h files in the OvmfPkg package

Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Andrew Fish <afish@apple.com>
2021-12-07 17:24:28 +00:00
Bob Feng 5a8bc527b3 OvmfPkg/LinuxInitrdDynamicShellCommand: Cast UNIT64 to UNITN in assignment
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2580

Ovmf build failed on Windows with VS2017 tool chain.
The error message like:

OvmfPkg\LinuxInitrdDynamicShellCommand\LinuxInitr
 dDynamicShellCommand.c(199): error C2220: warning treated as error -
 no 'object' file generated
OvmfPkg\LinuxInitrdDynamicShellCommand\LinuxInitrdDynamicShellCommand.c(199):
warning C4244: '=': conversion from 'UINT64' to 'UINTN',
possible loss of data

This patch is to cast UINT64 type to UINTN type
when doing the variable assignment.

Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-03-12 02:10:23 +00:00
Ard Biesheuvel 6c6fef0247 OvmfPkg/LinuxInitrdDynamicShellCommand: fix uninitialized status return
The Linaro CI reports:

  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:132:7:
  error: variable 'Status' is used uninitialized whenever 'if' condition is
                false [-Werror,-Wsometimes-uninitialized]
    if (mInitrdLoadFile2Handle != NULL) {
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:141:10:
  note: uninitialized use occurs here
    return Status;
           ^~~~~~
  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:132:3:
  note: remove the 'if' if its condition is always true
    if (mInitrdLoadFile2Handle != NULL) {
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:130:23:
  note: initialize the variable 'Status' to silence this warning
    EFI_STATUS    Status;
                      ^
                       = 0

Fix this by pulling the return of Status into the conditional block where
it is assigned, and return EFI_SUCCESS otherwise.

Fixes: 2632178bc6
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-03-04 17:42:43 +00:00
Ard Biesheuvel ecb30848fd OvmfPkg/LinuxInitrdDynamicShellCommand: bail if initrd already exists
Before taking any actions, check if an instance of the LoadFile2 exists
already on the Linux initrd media GUID device path, and whether it was
provided by this command. If so, abort, since no duplicate instances of
the device path should exist.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-03-04 09:26:45 +00:00
Ard Biesheuvel 2632178bc6 OvmfPkg: add 'initrd' shell command to expose Linux initrd via device path
Add a new 'initrd' command to the UEFI Shell that allows any file that is
accessible to the shell to be registered as the initrd that is returned
when Linux's EFI stub loader invokes the LoadFile2 protocol on its special
vendor media device path.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-03-04 09:26:45 +00:00