From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Thu, 11 Mar 2021 14:49:29 +0200
Subject: [PATCH 2/6] efi_loader: Add device path related functions for
 initrd via Boot####
In-Reply-To: <2a3425ba-87f1-8ff3-83a1-df2cc8d5e75a@gmx.de>
References: <20210305222303.2866284-1-ilias.apalodimas@linaro.org>
 <20210305222303.2866284-2-ilias.apalodimas@linaro.org>
 <3b72f7c0-5fc5-5dc9-c93f-43c40de9bdd4@gmx.de>
 <YEnelLeeLrnZYwcl@apalos.home>
 <3c7bca26-b4d6-88c5-611a-aaca1f224d39@gmx.de>
 <YEoApCa+XLG7HdvJ@apalos.home>
 <70AA1ED8-9F73-4D50-891A-1FCB855F7094@gmx.de>
 <09eb1814-05fe-2b97-af85-a6843082cac7@gmx.de>
 <YEoPblWI6qZZvdpD@apalos.home>
 <2a3425ba-87f1-8ff3-83a1-df2cc8d5e75a@gmx.de>
Message-ID: <YEoR2VuoZpx5FRkk@apalos.home>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.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
> >>>
> >>
>