grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC 0/2] UEFI-based HTTP Boot


From: Andrei Borzenkov
Subject: Re: [RFC 0/2] UEFI-based HTTP Boot
Date: Wed, 25 Jan 2017 12:01:29 +0300

On Wed, Jan 25, 2017 at 11:49 AM, Michael Chang <address@hidden> 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 <address@hidden> 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 <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]