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

[AKASHI Takahiro]

On Fri, Mar 12, 2021 at 06:42:14AM +0200, Ilias Apalodimas wrote:
> 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 I correctly remember, you had some discussions about this point
that UEFI specification is ambiguous here. Right?

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

OK.

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

Indeed.

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

My understanding is that none of existing boot loaders has not yet
supported such a concatenation (of either initrd or dtb) right now.
Do you (or linux's efistub?) intend to add a new feature?

-Takahiro Akashi


> 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