From: Ard Biesheuvel <ard.biesheuvel@linaro.org> To: Lukas Wunner <lukas@wunner.de> Cc: Ard Biesheuvel <ardb@kernel.org>, linux-efi <linux-efi@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Laszlo Ersek <lersek@redhat.com>, 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>, Heinrich Schuchardt <xypron.glpk@gmx.de>, Daniel Kiper <daniel.kiper@oracle.com> Subject: Re: [PATCH 1/2] efi/libstub: add support for loading the initrd from a device path Date: Sun, 9 Feb 2020 12:35:33 +0100 [thread overview] Message-ID: <CAKv+Gu-aV4REfOUpn7Ap2G6Rza9QFzfPRYU9d5hXvsJozDQNHw@mail.gmail.com> (raw) In-Reply-To: <20200209063907.fcwmwtiz2tjhjmol@wunner.de> On Sun, 9 Feb 2020 at 07:50, Lukas Wunner <lukas@wunner.de> wrote: > > On Thu, Feb 06, 2020 at 02:03:51PM +0000, Ard Biesheuvel wrote: > > --- a/drivers/firmware/efi/libstub/efistub.h > > +++ b/drivers/firmware/efi/libstub/efistub.h > > @@ -566,6 +566,14 @@ union efi_load_file_protocol { > > } mixed_mode; > > }; > > > > +struct efi_vendor_dev_path { > > + u8 type; > > + u8 sub_type; > > + u16 length; > > + efi_guid_t vendorguid; > > + u8 vendordata[]; > > +} __packed; > > In commit 46cd4b75cd0e ("efi: Add device path parser") I introduced a > struct efi_dev_path with a union for the type-specific data. Maybe > you can make use of it instead of introducing a new type? > That would make sense, but how do you take the size then? Perhaps it would be better to have a generic struct definition for the shared fields, struct definitions for the different types that use the generic type as the first fields, and a separate union that ties them altogether for the parser. > > > --- a/drivers/firmware/efi/libstub/efi-stub-helper.c > > +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c > > @@ -323,3 +323,68 @@ void efi_char16_printk(efi_char16_t *str) > > efi_call_proto(efi_table_attr(efi_system_table(), con_out), > > output_string, str); > > } > > + > > +static const struct { > > + struct efi_vendor_dev_path vendor; > > + struct efi_generic_dev_path end; > > +} __packed initrd_devpath = { > > Nit: Can we consistently stick to "dev_path" in lieu of "devpath"? > Sure.
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ard.biesheuvel@linaro.org> To: Lukas Wunner <lukas@wunner.de> Cc: linux-efi <linux-efi@vger.kernel.org>, Alexander Graf <agraf@csgraf.de>, Heinrich Schuchardt <xypron.glpk@gmx.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>, Laszlo Ersek <lersek@redhat.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: Sun, 9 Feb 2020 12:35:33 +0100 [thread overview] Message-ID: <CAKv+Gu-aV4REfOUpn7Ap2G6Rza9QFzfPRYU9d5hXvsJozDQNHw@mail.gmail.com> (raw) In-Reply-To: <20200209063907.fcwmwtiz2tjhjmol@wunner.de> On Sun, 9 Feb 2020 at 07:50, Lukas Wunner <lukas@wunner.de> wrote: > > On Thu, Feb 06, 2020 at 02:03:51PM +0000, Ard Biesheuvel wrote: > > --- a/drivers/firmware/efi/libstub/efistub.h > > +++ b/drivers/firmware/efi/libstub/efistub.h > > @@ -566,6 +566,14 @@ union efi_load_file_protocol { > > } mixed_mode; > > }; > > > > +struct efi_vendor_dev_path { > > + u8 type; > > + u8 sub_type; > > + u16 length; > > + efi_guid_t vendorguid; > > + u8 vendordata[]; > > +} __packed; > > In commit 46cd4b75cd0e ("efi: Add device path parser") I introduced a > struct efi_dev_path with a union for the type-specific data. Maybe > you can make use of it instead of introducing a new type? > That would make sense, but how do you take the size then? Perhaps it would be better to have a generic struct definition for the shared fields, struct definitions for the different types that use the generic type as the first fields, and a separate union that ties them altogether for the parser. > > > --- a/drivers/firmware/efi/libstub/efi-stub-helper.c > > +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c > > @@ -323,3 +323,68 @@ void efi_char16_printk(efi_char16_t *str) > > efi_call_proto(efi_table_attr(efi_system_table(), con_out), > > output_string, str); > > } > > + > > +static const struct { > > + struct efi_vendor_dev_path vendor; > > + struct efi_generic_dev_path end; > > +} __packed initrd_devpath = { > > Nit: Can we consistently stick to "dev_path" in lieu of "devpath"? > Sure. _______________________________________________ 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-09 11:35 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 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 [this message] 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=CAKv+Gu-aV4REfOUpn7Ap2G6Rza9QFzfPRYU9d5hXvsJozDQNHw@mail.gmail.com \ --to=ard.biesheuvel@linaro.org \ --cc=agraf@csgraf.de \ --cc=ardb@kernel.org \ --cc=daniel.kiper@oracle.com \ --cc=ilias.apalodimas@linaro.org \ --cc=leif@nuviainc.com \ --cc=lersek@redhat.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-efi@vger.kernel.org \ --cc=lukas@wunner.de \ --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: linkBe 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.