From: Ken Lin <ken.lin@hpe.com>
To: grub-devel@gnu.org
Cc: kengyu@hpe.com, clayc@hpe.com, michael.ruan@hpe.com, ljk@hpe.com,
Ken Lin <ken.lin@hpe.com>
Subject: [RFC 0/2] UEFI-based HTTP Boot
Date: Fri, 20 Jan 2017 09:13:19 +0800 [thread overview]
Message-ID: <1484874801-15420-1-git-send-email-ken.lin@hpe.com> (raw)
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
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
next reply other threads:[~2017-01-20 14:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-20 1:13 Ken Lin [this message]
2017-01-20 1:13 ` [RFC 1/2] net: add efihttp to do HTTP(S) Boot by UEFI HTTP Protocol Ken Lin
2017-01-20 1:13 ` [RFC 2/2] net: workaround to bypass corruption of the efihttp function pointer Ken Lin
2017-01-20 14:50 ` [RFC 0/2] UEFI-based HTTP Boot Andrei Borzenkov
2017-01-20 18:01 ` Chang, Clay (HPS OE-Linux TDC)
2017-01-21 3:37 ` Lin, Keng-Yu
2017-01-21 17:41 ` Andrei Borzenkov
2017-01-25 8:09 ` Michael Chang
2017-01-25 8:19 ` Andrei Borzenkov
2017-01-25 8:49 ` Michael Chang
2017-01-25 9:01 ` Andrei Borzenkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1484874801-15420-1-git-send-email-ken.lin@hpe.com \
--to=ken.lin@hpe.com \
--cc=clayc@hpe.com \
--cc=grub-devel@gnu.org \
--cc=kengyu@hpe.com \
--cc=ljk@hpe.com \
--cc=michael.ruan@hpe.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.