On Wed, Jan 25, 2017 at 11:49 AM, Michael Chang <mch...@suse.com> wrote: > 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. >
These patches hook into network stack of grub. So they either must comply with this stack (which means - provide alternative network driver for reasons I mentioned) or they must pretend "efihttp" is disk. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
