[PATCH 2/6] efi_loader: Add device path related functions for initrd via Boot####

[AKASHI Takahiro <takahiro.akashi@linaro.org>]

On Fri, Mar 12, 2021 at 06:10:29AM +0200, Ilias Apalodimas wrote:
> Akashi-san, 
> 
> On Fri, Mar 12, 2021 at 11:50:32AM +0900, AKASHI Takahiro wrote:
> > Ilias,
> > 
> > I may have missed your past discussions, but any way,
> 
> It's on the boot-architecture mailing list [1] 
> 
> > 
> > On Thu, Mar 11, 2021 at 01:36:04PM +0200, Ilias Apalodimas wrote:
> > > > 
> 
> [...]
> 
> > > > My understanding is that we have:
> > > > 
> > > > kernel path,end(0xff),
> > > > VenMedia(), /* no end node here */
> > > > initrd1, end(0x01),
> > > > initrd2, end(0xff)
> > > 
> > > 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),
> > >  initrd1, end(0x01),
> > >  initrd2, end(0xff)
> > 
> > What is the difference between end(0xff) and end(0x01)?
> > 
> 
> 0xff is a subtype of 'end the entire device path', while 0x01 is an 'end of
> instance of a device path and start a new device path'
> 
> > If the first argument of a load option is a list of device paths,
> > I would expect the format would look like:
> >   kernel path,end(0xff),
> >   VenMedia(INITRD),initrd1 path,end(0xff),
> >   VenMedia(INITRD),initrd2 path,end(0xff),
> > 
> > so that VenMedia can work as an identify of the succeeding path.
> > Is it simple enough, isn't it?
> 
> It's essentially the same thing. It has an effect on the EFI spec and how you
> interpret it, but honestly it feels as an implementation detail to me, since
> none of those are standardized anyway.
> 
> In fact what you are saying was part of my proposal in the original mail
> (check proposal 1.)
> 
> Anyway the difference between the two is that what I coded looks like this:
> FilePathList[0] -> kernel
> FilePathList[1] -> initrd1 - initrdn
> 
> while whe other is
> FilePathList[0] -> kernel
> FilePathList[1] -> initrd1 
> FilePathList[2] -> initrd2
> FilePathList[n] -> initrdn
> 
> If we ever manage to wire in the DTBs in there as well it may look like:
> 
> FilePathList[0] -> kernel
> FilePathList[1] -> initrd1 - initrdn
> FilePathList[2] -> dtb1 - dtbn
> 
> Vs
> 
> FilePathList[0] -> kernel
> FilePathList[1] -> initrd1 
> FilePathList[2] -> initrd2
> FilePathList[3] -> dtb1
> FilePathList[n] -> initrdn
> FilePathList[n+1] -> dtb2

What is the semantics?
Which do you want to do?
a) boot one of combinations:
     1.kernel+initrd1+dtb1, or
     2.kernel+initrd2+dtb2
b) boot
     kernel + (initrd1 + initrd2) + (dtb1 + dtb2)

I assume you meant (a).
In that case, how can you specify (a-1) or (a-2) at boot time?

Is there any clear description about that?
(I"m simply asking here.)

-Takahiro Akashi

> 
> 
> > 
> > -Takahiro Akashi
> > 
> > > 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
> 
> [1] https://lists.linaro.org/pipermail/boot-architecture/2021-February/001686.html
> 
> Cheers
> /Ilias