[PATCH 6/8 v2] efi_loader: Replace config option with EFI variable for initrd loading

[Ilias Apalodimas]

> >>>

[...]

> >>> If so, the content of "Initrd####" should contain a generic EFI
> >>> representation of file path.
> >>> Please note that "Boot####" internally contains a flattened string of
> >>> "EFI device path" to the image while efidebug command accepts a style of
> >>> "mmc 0:1 image" as arguments to "efidebug boot add" sub-command.
> >>
> >> Thanks for the pointers. I've already changed the patchset and using exactly
> >> what you described. This has another advantage, all the helper files for the
> >> string parsing previous patches introduce, went away as well.
> >>
> >
> > While I was trying to code this I came across a few things that we
> > need to resolve before posting my v3.
> > This feature is supposed to be very specific in linux so each OS
> > loader can decide on how to expose and
> > load the corresponding initrd.
> >
> > Moving the contents to a device path adds more problems that it solves
> > at the moment.
> > First of all we'll be forced to use efi_load_image_from_file(), which
> 
> You are not obliged to call efi_load_image_from_file(). You could
> implement your own function.
> 
> Or you could add a check *buffer!=NULL to detect a pre-allocated buffer
> and neither allocate nor free the buffer in this case.

Right obliged was a poor choice of words. I was just trying to point out
issues with using the current U-Boot functions.

> 
> > uses EFI_SIMPLE_FILESYSTEM_PROTOCOL
> > and EFI_FILE_PROTOCOL to eventually load the file. This has 2
> > problems. We'll have to place the initrd on the same
> > filesystem the image we load resides (as opposed to my patch where the
> > initrd can be anywhere).
> 
> Given Boot#### contains
> 
>     dp1<sep>dp2<sep>dp3<end>

Let's clarify this a bit first so other people can join the discussion.

What I proposed yesterday to Heinrich, since we can use a device path
directly, is store it in the EFI_LOAD_OPTION we construct when we add the 
Boot#### variables. 
According to the EFI spec FilePathList is an array of device paths. 
The first element of the array is a device path that describes the 
device and location of the Image for this load option, but the rest are OS
specific, so we might as well use them instead of using a custom EFI variable.

Ok I'll send a v3 implementing this idea + a new function that can consume the 
device path and load a file without using EFI_SIMPLE_FILESYSTEM_PROTOCOL.
That would probablty solve all our problems.


Cheers
/Ilias


> 
> when calling efi_load_image_from_file() three times, once for dp1, dp2,
> dp3, each of these device paths can point to a different block device.
> 
> Best regards
> 
> Heinrich
> 
> > Apart from that calling efi_load_image_from_file() will try to free
> > the memory on errors, but that memory is allocated
> > and managed by the efi-stub.
> >
> > I'd prefer keeping the implementation as is, unless someone has a better idea.
> >
> > Thoughts?
> >
> > Cheers
> > /Ilias
> >
> >
> > [...]
> >
>