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

[Leif Lindholm <leif.lindholm@linaro.org>]

On Tue, Oct 24, 2017 at 02:10:44PM +0200, Laszlo Ersek wrote:
> 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?

Convenience. And given that I only noticed yesterday that the boot
fails on HTTP redirects, of somewhat restricted value.

Is that an official policy decision, or just a restriction of the
implementation?

> 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.

These were exactly the kinds of things I meant about "how best to
implement" (without trying to answer them myself).

Regards,

Leif