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

[Ilias Apalodimas]

On Fri, Mar 12, 2021 at 01:32:50PM +0900, AKASHI Takahiro 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.)

it's b) 
if you want different combinations of kernel/initrds (as described in a) you
can add another Boot#### variable.

So let's assume you got three boot options
Boot0000, Boot0001 and Boot0002

Boot0000 efi_load_options: kernel1 + (initrd1 + initrd2) + (dtb1 + dtb2). 
The bootloader will concat initrd1+initrd2 when the kernel requests it.
Similar behavior can be coded for dtb before installing the table.

Boot0001: kernel1 + initrd1 + dtb1
Load a kernel with a single initrd and dtb.

Boot0002: kernel2 + initrd2 + dtb2
ditto.

Hope that's clear now

Cheers
/Ilias


> 
> -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