From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:400c:c09::243; helo=mail-wm0-x243.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 89F4A203525E4 for ; Tue, 24 Oct 2017 05:32:26 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id z3so9007312wme.5 for ; Tue, 24 Oct 2017 05:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=pRDz4F1xJPWcTFEhkARGsJbvEorTPMjEIMuu+om0b4Y=; b=F4ZH1ile471Pl2BZchpxOn8yvMSq7mjzdYoRNctxyeeo2gDETA+TNZoKuaXWVuSCN/ 3CbT6+8Fxs4ukaeXekanuZulxcHiip4z5PhVHM0VY8hrE6x/4Q4VJbW+nV7/WW98q/eL 0FmLSz0CUYroY/ZcPq0s1JW2p5NrAZShG6viA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=pRDz4F1xJPWcTFEhkARGsJbvEorTPMjEIMuu+om0b4Y=; b=PO7gCo7wDkQv7JCO+KdI0oioSx5EbYcN1JwoWza+epBjGpGfZQ6BlXhr+fcyvkfOGX gvOI9bQc06l3CSSBF/pC15FodFKaXrRM+7YVK+qaAmMYleKVnlC96iJCG1DRfIY4kUmT ZqVHClKrPUZnxkDK7CajEnlxNHBHzOaB5xjchacr1IuQjjccnvGU8Q5PYIfpwebKa8zy WGBfiOPVOrsrI6fbOLZKpEozXntX0HpmJ5IZ0/aAi5E7YeqkZazTiaQn9i35+xOYDNad MsvhA9jz9hHm1cDzcGRXGCLIRvno/I3hYn4WMZCr2J4ZRDJYPnfxTO02tV3lh0ps7vMT w70Q== X-Gm-Message-State: AMCzsaXvle+r/EyD9Ves7HsVX/LiJ81Kul1JHYsR01Ms4I9khXLgpIBi uMMQMNlWMIiBNCqzYLEhaNWVsg== X-Google-Smtp-Source: ABhQp+QEo8TP80mu9lu0qjKiyuWsWR7kDvbpxUY/q/skADHcBc5sfVrD0tMLHb1l5zkH6IBvVPEDVA== X-Received: by 10.28.137.193 with SMTP id l184mr7825201wmd.24.1508848568642; Tue, 24 Oct 2017 05:36:08 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id 188sm179875wmg.45.2017.10.24.05.36.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Oct 2017 05:36:07 -0700 (PDT) Date: Tue, 24 Oct 2017 13:36:06 +0100 From: Leif Lindholm To: Laszlo Ersek Cc: Ard Biesheuvel , edk2-devel@lists.01.org, daniel.thompson@linaro.org Message-ID: <20171024123605.mpcyaemq55s6v7e2@bivouac.eciton.net> References: <20171021131049.23844-1-ard.biesheuvel@linaro.org> <0f440c7d-f590-57c1-9f34-f9c8a54c81d6@redhat.com> MIME-Version: 1.0 In-Reply-To: <0f440c7d-f590-57c1-9f34-f9c8a54c81d6@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [RFC PATCH] ArmPkg: add driver to add distro installer HTTP boot options X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 12:32:26 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 > > --- > > > > 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