All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: u-boot@lists.denx.de
Subject: [PATCH 2/6] efi_loader: Add device path related functions for initrd via Boot####
Date: Thu, 11 Mar 2021 14:49:29 +0200	[thread overview]
Message-ID: <YEoR2VuoZpx5FRkk@apalos.home> (raw)
In-Reply-To: <2a3425ba-87f1-8ff3-83a1-df2cc8d5e75a@gmx.de>

On Thu, Mar 11, 2021 at 01:44:05PM +0100, Heinrich Schuchardt wrote:
> On 11.03.21 13:39, Ilias Apalodimas wrote:
> > Hi Heinrich,
> >
> > [...]
> >>>> No, the structure is added in cmd/efidebug.c code.
> >>>> It's created with efi_dp_append_instance() on
> >>>> - const struct efi_initrd_dp id_dp
> >>>> - file path of initrd
> >>>>
> >>>> which will create:
> >>>> kernel path,end(0xff),
> >>>> VenMedia(), end(0x01),
> >>
> >> This end node is superfluous.
> >
> > Why?i It's not defined in any standard (in fact these patches will be used for
> > the USWG proposal), it's making our lives a lot easier during parsing, since
> > you only need to get the next instance for the *entire* device path.
> > On the other hand if you mix and match them, you'll have to skip the first
> > entry with dp->len and then start using code to get the next instance. Similar
> > logic applies to appending the instance obviously. Since you now how have to
> > account for your 'special' first node, which isn't that special to begin with.
> >
> > So why exactly is it superflous? Because you can get the next initrd without
> > having to parse an end of instace? Well that's the case for the initrd's as
> > well then ....
> > On the contrary I think it makes the entire device path look more generic,
> > since each node is separated by an end of instance, no matter what the
> > contents are.
> 
> We use the VenMedia() node to identify a multi-part device tree
> containing one or multiple initrd.
> 
> An end node does not convey any additional information.
> 
> The first initrd device path can start directly behind the VenMedia()
> node. This saves space for non-volatile variables which is limited.
> 

Again, it can. But we can also remove the end node after each initrd no?
Then we'd save even more space...

My point is, I can't understand why we should complicate the adding
code/parsing code, by adding a special use case.
I don't think saving 4bytes is really worth the complexity.

Thanks
/Ilias
> Best regards
> 
> Heinrich
> 
> >
> > Thanks
> > /Ilias
> >
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >>>> initrd1, end(0x01),
> >>>> initrd2, end(0xff)
> >>>>
> >>>> I know I originally proposed the one you have, but it seemed cleaner
> >>>> adding
> >>>> an extra instance between VenMedia and the first initrd.
> >>>>
> >>>>>
> >>>>> Please, document the structure.
> >>>>>
> >>>>
> >>>> Sure
> >>>>
> >>>>> Best regards
> >>>>>
> >>>>> Heinrich
> >>>>
> >>>> Thanks
> >>>> /Ilias
> >>>
> >>
> 

  reply	other threads:[~2021-03-11 12:49 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05 22:22 [PATCH 1/6] efi_selftest: Remove loadfile2 for initrd selftests Ilias Apalodimas
2021-03-05 22:22 ` [PATCH 2/6] efi_loader: Add device path related functions for initrd via Boot#### Ilias Apalodimas
2021-03-11  7:50   ` Heinrich Schuchardt
2021-03-11  9:10     ` Ilias Apalodimas
2021-03-11 11:00       ` Heinrich Schuchardt
2021-03-11 11:36         ` Ilias Apalodimas
2021-03-11 11:44           ` Heinrich Schuchardt
2021-03-11 12:31             ` Heinrich Schuchardt
2021-03-11 12:39               ` Ilias Apalodimas
2021-03-11 12:44                 ` Heinrich Schuchardt
2021-03-11 12:49                   ` Ilias Apalodimas [this message]
2021-03-11 13:31             ` Ilias Apalodimas
2021-03-11 20:25               ` Heinrich Schuchardt
2021-03-12  2:50           ` AKASHI Takahiro
2021-03-12  4:10             ` Ilias Apalodimas
2021-03-12  4:32               ` AKASHI Takahiro
2021-03-12  4:42                 ` Ilias Apalodimas
2021-03-12  5:02                   ` AKASHI Takahiro
2021-03-12  5:19                     ` Ilias Apalodimas
2021-03-05 22:22 ` [PATCH 3/6] efi_loader: Introduce helper functions for EFI Ilias Apalodimas
2021-03-11  9:15   ` Heinrich Schuchardt
2021-03-05 22:23 ` [PATCH 4/6] efi_loader: Replace config option for initrd loading Ilias Apalodimas
2021-03-11 12:23   ` Heinrich Schuchardt
2021-03-11 12:30     ` Ilias Apalodimas
2021-03-11 12:50       ` Heinrich Schuchardt
2021-03-05 22:23 ` [PATCH 5/6] efidebug: add multiple device path instances on Boot#### Ilias Apalodimas
2021-03-11 12:38   ` Heinrich Schuchardt
2021-03-11 12:42     ` Ilias Apalodimas
2021-03-12  4:44   ` AKASHI Takahiro
2021-03-12  4:55     ` Ilias Apalodimas
2021-03-12  5:23       ` AKASHI Takahiro
2021-03-12  5:37         ` Ilias Apalodimas
2021-03-12  5:58           ` AKASHI Takahiro
2021-03-12  7:19             ` Ilias Apalodimas
2021-03-12 16:25     ` Heinrich Schuchardt
2021-03-05 22:23 ` [PATCH 6/6] doc: Update uefi documentation for initrd loading options Ilias Apalodimas
2021-03-11 12:39   ` Heinrich Schuchardt
2021-03-11  7:26 ` [PATCH 1/6] efi_selftest: Remove loadfile2 for initrd selftests Heinrich Schuchardt
2021-03-13 21:47 [PATCH 0/6 v2] Loadfile2 for initrd loading Ilias Apalodimas
2021-03-13 21:47 ` [PATCH 2/6] efi_loader: Add device path related functions for initrd via Boot#### Ilias Apalodimas
2021-03-14  7:19   ` Heinrich Schuchardt
2021-03-14  7:32     ` Ilias Apalodimas

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=YEoR2VuoZpx5FRkk@apalos.home \
    --to=ilias.apalodimas@linaro.org \
    --cc=u-boot@lists.denx.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.