On Wed, Jan 25, 2017 at 11:19:19AM +0300, Andrei Borzenkov wrote: > On Wed, Jan 25, 2017 at 11:09 AM, Michael Chang <mch...@suse.com> 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 <ken....@hpe.com> 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
