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: Chang, Clay (HPS OE-Linux TDC)
Subject: Re: [RFC 0/2] UEFI-based HTTP Boot
Date: Fri, 20 Jan 2017 18:01:35 +0000
User-agent: Microsoft-MacOutlook/f.1e.0.170107

Hi Andrei,

We didn’t “re-implement” the existing http feature in grub2. What we do is 
putting a piece of code to check the availability of the http protocol in the 
firmware. If available, we use the http protocol offered by the firmware. If 
not, we follow the original http path.

Does this make sense to you?

Regards,
Clay

On 1/20/17, 10:50 PM, "Andrei Borzenkov" <address@hidden> 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.
    
    > 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
    > address@hidden
    > https://lists.gnu.org/mailman/listinfo/grub-devel
    


reply via email to

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