Re: [RFC PATCH] ArmPkg: add driver to add distro installer HTTP boot options

[Laszlo Ersek <lersek@redhat.com>]

On 10/21/17 15:10, Ard Biesheuvel wrote:
> To make it easier for power users to provision a 'desktop' system [as
> opposed to a VM or server] from scratch, introduce a driver that adds
> boot options to the boot menu that can launch network installers over
> HTTP straight off the Internet.
> 
> Currently, this only supports the 'mini.iso' style netboot installers
> that Debian/Ubuntu provide: larger images that need to be mounted by
> the installer when running under the Linux kernel are only supported
> on ACPI systems with support for the NFIT table, and this was enabled
> only recently (Linux v4.14) for arm64. For DT boot, there is currently
> no way at all to expose ramdisks created by UEFI as block devices in
> Linux.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> 
> Posted as an RFC because:
> a) Where does this belong? Surely not in ArmPkg but I had to put it somewhere
> b) Currently, the way the options are created results in them taking priority
>    if no real boot options were set (i.e., for GRUB).
> c) Is there a use case for downloading 300-500 MB installers off the Internet
>    for a one shot installation? Or should we just stick to the mini.iso flavors.
> d) Did I miss any distros we may care about?
> 
>  ArmPkg/Drivers/OsInstallerMenuDxe/OsInstallerMenuDxe.c   | 228 ++++++++++++++++++++
>  ArmPkg/Drivers/OsInstallerMenuDxe/OsInstallerMenuDxe.inf |  42 ++++
>  2 files changed, 270 insertions(+)

https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot

If the HTTP Boot stack is built into the firmware, it is possible to
navigate to:

  Device Manager
    Network Device List
      MAC:xx:xx:xx:xx:xx:xx
        HTTP Boot Configuration

On this dialog, we have
- "Input the description"
- "Internet protocol"
- "Boot URI"

The help text says, "A new Boot Option will be created according to this
Boot URI".

Therefore, I think the functionality already exists (for power users
that are willing to pick a NIC and to type a URL, anyway).

Is the goal of your patch to provide more convenience, or to provide the
base functionality?

Also, I think that creating baked-in boot options belongs with the
platform's PlatformBootManagerLib instance, not a separate UEFI_DRIVER
module. (That's where the UEFI shell boot option is created already, for
example.) Platform BDS is responsible for connecting NICs (none of them,
some of them, all of them -- and recursively or non-recursively), so if
you want to look at specific NIC-related protocol instances, you know
exactly when to look.

If the goal is really to save the user the typing of one URL, then I
suggest to implement this feature as a small, standalone library, under
edk2-platforms; with a sole API called CreateOsInstallerBootOptions().

Then, interested platforms may invoke CreateOsInstallerBootOptions() in
their PlatformBootManagerLib instances.

(This would be similar to:

  OvmfPkg/Include/Library/QemuBootOrderLib.h
  OvmfPkg/Library/QemuBootOrderLib/

and how we call SetBootOrderFromQemu() in ArmVirtPkg's and OvmfPkg's
PlatformBootManagerLib instances.)

Perhaps you can introduce the lib class, with a Null instance, in edk2
as well; and then call the new API in

  ArmPkg/Library/PlatformBootManagerLib

at the right spot. (I think adding the API / lib class to edk2 makes
sense, but I also think the lib instance with the actual URLs should
live under edk2-platforms, somewhere.)

Just my two cents.

Thanks!
Laszlo