From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1cWJHY-0003nD-5D for mharc-grub-devel@gnu.org; Wed, 25 Jan 2017 03:50:20 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cWJHV-0003lp-Nf for grub-devel@gnu.org; Wed, 25 Jan 2017 03:50:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cWJHR-0001vU-Nu for grub-devel@gnu.org; Wed, 25 Jan 2017 03:50:17 -0500 Received: from smtp.nue.novell.com ([195.135.221.5]:59967) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cWJHR-0001uS-Dv for grub-devel@gnu.org; Wed, 25 Jan 2017 03:50:13 -0500 Received: from nwb-ext-pat.microfocus.com ([10.120.13.103]) by smtp.nue.novell.com with ESMTP (TLS encrypted); Wed, 25 Jan 2017 09:50:11 +0100 Received: from linux-9gqx.suse.de (nwb-a10-snat.microfocus.com [10.120.13.201]) by nwb-ext-pat.microfocus.com with ESMTP (TLS encrypted); Wed, 25 Jan 2017 08:50:00 +0000 Date: Wed, 25 Jan 2017 16:49:53 +0800 From: Michael Chang To: The development of GNU GRUB Cc: Ken Lin , "Chang, Clay (HPS OE-Linux TDC)" , kengyu@hpe.com, ljk@hpe.com, "Ruan, Michael (HPS OE-Linux/VMware TDC)" Subject: Re: [RFC 0/2] UEFI-based HTTP Boot Message-ID: <20170125084953.GE16351@linux-9gqx.suse.de> Mail-Followup-To: The development of GNU GRUB , Ken Lin , "Chang, Clay (HPS OE-Linux TDC)" , kengyu@hpe.com, ljk@hpe.com, "Ruan, Michael (HPS OE-Linux/VMware TDC)" References: <1484874801-15420-1-git-send-email-ken.lin@hpe.com> <20170125080946.GC16351@linux-9gqx.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 195.135.221.5 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 08:50:19 -0000 On Wed, Jan 25, 2017 at 11:19:19AM +0300, Andrei Borzenkov wrote: > On Wed, Jan 25, 2017 at 11:09 AM, Michael Chang wrote: > > On Fri, Jan 20, 2017 at 05:50:56PM +0300, Andrei Borzenkov wrote: > >> On Fri, Jan 20, 2017 at 4:13 AM, Ken Lin wrote: > >> > This RFC patchset is stacked on the previous HTTP boot patchset: > >> > https://lists.gnu.org/archive/html/grub-devel/2016-12/msg00088.html > >> > It re-uses some code from it, e.g. the DCHPACK > >> > with vendor_class_identifier=HTTPClient. > >> > > >> > Instead of implementing HTTP and HTTPS boot totally from software, > >> > UEFI firmware already defines APIs for HTTP(s). > >> > Please check UEFI spec. 2.5 and plus for the detail: > >> > > >> > 28.6 EFI HTTP Protocols > >> > > >> > >> Without reviewing patches themselves - we usually prefer to rely on > >> firmware as little as possible. We already have HTTP support, so what > >> is missing in grub that requires what amounts to full > >> re-implementation? Cannot we rather fix our HTTP support instead? This > >> will automatically benefit all supported platforms, of which EFI is > >> just one. > > > > Nothing wrong in providing firmware based approach in addition to grub's native > > stack of getting the similar things done. > > You cannot both shut off all layered protocols on physical adapter and > makes use of these layered protocols. This will need to implement > alternative networking stack first. They don't have to be runtime switch to operate at the same time. Make them distinct modules, and provid a swith for controlling the image being built. We already have --native switch in grub2-install to incorporate native disk modules rather than firmware's. Thanks, Michael > > > And there's no prioity for what has > > to be implemented first imho. Occasionally people would prefer firmware based > > stack because they need new features it provides that haven't been worked out > > in grub, such as the https or fibre networks, or simply to avoid bug from grub, > > like the SNP woes among some UEFI box. > > > > Thanks, > > Michael > > > >> > >> > Then why two implementations? For older UEFI firmwares (UEFI 2.4 and older), > >> > the HTTP(s) APIs are not available. In the case, > >> > Grub can fall back to the software-based implementation. > >> > In the first patch of this patchset, grub-core/net/drivers/efi/efihttp.c:76 to 81 > >> > is the code to query if the HTTP Protocol is supported by the UEFI firmware. > >> > > >> > This patchset was tested on QEMU+OVMF and it works flawlessly. > >> > > >> > The main goals of this RFC is to ask for opinions and suggestion to make > >> > the first patch modularized as much as possible. > >> > In the second patch, there is some codes related TCP re-transmission > >> > that need to pass by for the HTTP Boot to work. > >> > > >> > More details are described in the logs of each patch. > >> > > >> > > >> > Ken Lin (2): > >> > net: add efihttp to do HTTP(S) Boot by UEFI HTTP Protocol > >> > net: workaround to bypass corruption of the efihttp function pointer > >> > > >> > grub-core/Makefile.core.def | 1 + > >> > grub-core/net/bootp.c | 6 + > >> > grub-core/net/drivers/efi/efihttp.c | 386 ++++++++++++++++++++++++++++++++++++ > >> > grub-core/net/drivers/efi/efinet.c | 1 + > >> > grub-core/net/net.c | 39 +++- > >> > include/grub/efi/api.h | 17 ++ > >> > include/grub/efi/http.h | 221 +++++++++++++++++++++ > >> > include/grub/err.h | 3 +- > >> > include/grub/net.h | 1 + > >> > 9 files changed, 672 insertions(+), 3 deletions(-) > >> > create mode 100755 grub-core/net/drivers/efi/efihttp.c > >> > create mode 100755 include/grub/efi/http.h > >> > > >> > -- > >> > 2.7.4 > >> > > >> > > >> > _______________________________________________ > >> > Grub-devel mailing list > >> > Grub-devel@gnu.org > >> > https://lists.gnu.org/mailman/listinfo/grub-devel > >> > >> _______________________________________________ > >> Grub-devel mailing list > >> Grub-devel@gnu.org > >> https://lists.gnu.org/mailman/listinfo/grub-devel > > > > _______________________________________________ > > Grub-devel mailing list > > Grub-devel@gnu.org > > https://lists.gnu.org/mailman/listinfo/grub-devel > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel