From: Laszlo Ersek <lersek@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ard Biesheuvel <ardb@kernel.org>,
linux-efi <linux-efi@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Leif Lindholm <leif@nuviainc.com>,
Peter Jones <pjones@redhat.com>,
Matthew Garrett <mjg59@google.com>,
Alexander Graf <agraf@csgraf.de>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Daniel Kiper <daniel.kiper@oracle.com>
Subject: Re: [PATCH 1/2] efi/libstub: add support for loading the initrd from a device path
Date: Fri, 7 Feb 2020 12:09:45 +0100 [thread overview]
Message-ID: <ecc0febc-b964-5754-580f-7514427a068d@redhat.com> (raw)
In-Reply-To: <CAKv+Gu9Z24GeqrqKhPJN+aAu8crSKvT0ZBeFL=0ik=z2Sd1FmQ@mail.gmail.com>
On 02/06/20 23:35, Ard Biesheuvel wrote:
> On Thu, 6 Feb 2020 at 18:26, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>> When booting via GRUB it will be GRUB knowing which initrd to load.
>>
>
> Exactly, which is why GRUB will implement this protocol. That way, it
> does not have to touch the DT at all, or create a bootparams struct
> from setup data and inspect the various flags about placement,
> alignment, preferred addresses, etc.
>
>> Please, indicate which software you expect to expose the initrd related
>> EFI_LOAD_FILE2_PROTOCOL.
>>
>
> The primary use case is GRUB and other intermediate loaders, since it
> would remove any need for these components to know any such details.
> My aim is to make the next architecture that gets added to GRUB for
> EFI boot 100% generic.
Understood, thanks. It sounds plausible to me.
Laszlo
WARNING: multiple messages have this Message-ID (diff)
From: Laszlo Ersek <lersek@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: linux-efi <linux-efi@vger.kernel.org>,
Alexander Graf <agraf@csgraf.de>,
Daniel Kiper <daniel.kiper@oracle.com>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Matthew Garrett <mjg59@google.com>,
Peter Jones <pjones@redhat.com>,
Leif Lindholm <leif@nuviainc.com>,
Ard Biesheuvel <ardb@kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/2] efi/libstub: add support for loading the initrd from a device path
Date: Fri, 7 Feb 2020 12:09:45 +0100 [thread overview]
Message-ID: <ecc0febc-b964-5754-580f-7514427a068d@redhat.com> (raw)
In-Reply-To: <CAKv+Gu9Z24GeqrqKhPJN+aAu8crSKvT0ZBeFL=0ik=z2Sd1FmQ@mail.gmail.com>
On 02/06/20 23:35, Ard Biesheuvel wrote:
> On Thu, 6 Feb 2020 at 18:26, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>> When booting via GRUB it will be GRUB knowing which initrd to load.
>>
>
> Exactly, which is why GRUB will implement this protocol. That way, it
> does not have to touch the DT at all, or create a bootparams struct
> from setup data and inspect the various flags about placement,
> alignment, preferred addresses, etc.
>
>> Please, indicate which software you expect to expose the initrd related
>> EFI_LOAD_FILE2_PROTOCOL.
>>
>
> The primary use case is GRUB and other intermediate loaders, since it
> would remove any need for these components to know any such details.
> My aim is to make the next architecture that gets added to GRUB for
> EFI boot 100% generic.
Understood, thanks. It sounds plausible to me.
Laszlo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-02-07 11:09 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 14:03 [PATCH 0/2] arch-agnostic initrd loading method for EFI systems Ard Biesheuvel
2020-02-06 14:03 ` Ard Biesheuvel
2020-02-06 14:03 ` [PATCH 1/2] efi/libstub: add support for loading the initrd from a device path Ard Biesheuvel
2020-02-06 14:03 ` Ard Biesheuvel
2020-02-06 18:26 ` Heinrich Schuchardt
2020-02-06 18:26 ` Heinrich Schuchardt
2020-02-06 18:46 ` Ilias Apalodimas
2020-02-06 18:46 ` Ilias Apalodimas
2020-02-06 19:15 ` Heinrich Schuchardt
2020-02-06 19:15 ` Heinrich Schuchardt
2020-02-06 20:09 ` Ilias Apalodimas
2020-02-06 20:09 ` Ilias Apalodimas
2020-02-06 22:49 ` Heinrich Schuchardt
2020-02-06 22:49 ` Heinrich Schuchardt
2020-02-07 7:35 ` Ilias Apalodimas
2020-02-07 7:35 ` Ilias Apalodimas
2020-02-06 22:35 ` Ard Biesheuvel
2020-02-06 22:35 ` Ard Biesheuvel
2020-02-07 0:01 ` Heinrich Schuchardt
2020-02-07 0:01 ` Heinrich Schuchardt
2020-02-07 0:21 ` Ard Biesheuvel
2020-02-07 0:21 ` Ard Biesheuvel
2020-02-07 0:57 ` Heinrich Schuchardt
2020-02-07 0:57 ` Heinrich Schuchardt
2020-02-07 8:12 ` Ard Biesheuvel
2020-02-07 8:12 ` Ard Biesheuvel
2020-02-07 13:30 ` Heinrich Schuchardt
2020-02-07 13:30 ` Heinrich Schuchardt
2020-02-07 13:58 ` Ard Biesheuvel
2020-02-07 13:58 ` Ard Biesheuvel
2020-02-07 14:18 ` Alexander Graf
2020-02-07 14:18 ` Alexander Graf
2020-02-07 15:30 ` Ard Biesheuvel
2020-02-07 15:30 ` Ard Biesheuvel
2020-02-07 15:35 ` Heinrich Schuchardt
2020-02-07 15:35 ` Heinrich Schuchardt
2020-02-07 11:09 ` Laszlo Ersek [this message]
2020-02-07 11:09 ` Laszlo Ersek
2020-02-07 11:03 ` Laszlo Ersek
2020-02-07 11:03 ` Laszlo Ersek
2020-02-07 9:48 ` Laszlo Ersek
2020-02-07 9:48 ` Laszlo Ersek
2020-02-07 12:36 ` Ard Biesheuvel
2020-02-07 12:36 ` Ard Biesheuvel
2020-02-10 14:26 ` Laszlo Ersek
2020-02-10 14:26 ` Laszlo Ersek
2020-02-09 6:39 ` Lukas Wunner
2020-02-09 11:35 ` Ard Biesheuvel
2020-02-09 11:35 ` Ard Biesheuvel
2020-02-06 14:03 ` [PATCH 2/2] efi/libstub: take noinitrd cmdline argument into account for devpath initrd Ard Biesheuvel
2020-02-06 14:03 ` Ard Biesheuvel
2020-02-06 18:33 ` Heinrich Schuchardt
2020-02-06 18:33 ` Heinrich Schuchardt
2020-02-06 23:44 ` Ard Biesheuvel
2020-02-06 23:44 ` Ard Biesheuvel
2020-02-12 16:01 ` Peter Jones
2020-02-12 16:01 ` Peter Jones
2020-02-07 9:09 ` [PATCH 0/2] arch-agnostic initrd loading method for EFI systems Laszlo Ersek
2020-02-07 9:09 ` Laszlo Ersek
2020-02-07 9:22 ` Laszlo Ersek
2020-02-07 9:22 ` Laszlo Ersek
2020-02-07 12:23 ` Ard Biesheuvel
2020-02-07 12:23 ` Ard Biesheuvel
2020-02-07 16:20 ` James Bottomley
2020-02-07 16:20 ` James Bottomley
2020-02-07 18:31 ` Ard Biesheuvel
2020-02-07 18:31 ` Ard Biesheuvel
2020-02-07 19:54 ` James Bottomley
2020-02-07 19:54 ` James Bottomley
2020-02-07 20:03 ` Ard Biesheuvel
2020-02-07 20:03 ` Ard Biesheuvel
2020-02-07 18:45 ` Arvind Sankar
2020-02-07 18:45 ` Arvind Sankar
2020-02-07 19:47 ` Ard Biesheuvel
2020-02-07 19:47 ` Ard Biesheuvel
2020-02-07 20:26 ` Arvind Sankar
2020-02-07 20:26 ` Arvind Sankar
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=ecc0febc-b964-5754-580f-7514427a068d@redhat.com \
--to=lersek@redhat.com \
--cc=agraf@csgraf.de \
--cc=ard.biesheuvel@linaro.org \
--cc=ardb@kernel.org \
--cc=daniel.kiper@oracle.com \
--cc=ilias.apalodimas@linaro.org \
--cc=leif@nuviainc.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=mjg59@google.com \
--cc=pjones@redhat.com \
--cc=xypron.glpk@gmx.de \
/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.