Re: [PATCH RFC/RFT 0/3] Add grub loader support for RISC-V Linux

[Ard Biesheuvel]

On Mon, 27 Apr 2020 at 22:47, Heinrich Schuchardt <address@hidden> wrote:
>
> Am April 27, 2020 7:39:38 PM UTC schrieb Ard Biesheuvel <address@hidden>:
> >On Mon, 27 Apr 2020 at 21:36, Heinrich Schuchardt <address@hidden>
> >wrote:
> >>
> >> On 4/27/20 1:01 PM, Daniel Kiper wrote:
> >> > On Mon, Apr 27, 2020 at 08:15:41AM +0200, Ard Biesheuvel wrote:
> >> >> On Sun, 26 Apr 2020 at 21:40, Atish Patra <address@hidden>
> >wrote:
> >> >>>
> >> >>> This series adds grub loader support for RISC-V Linux. Thanks to
> >the awesome
> >> >>> initial RISC-V support added by Alex, we just needed a loader for
> >RISC-V to
> >> >>> load and execute Linux using UEFI protocol.
> >> >>>
> >> >>> Fortunately, ARM64 Linux loader is written in an architecture
> >agnostic manner
> >> >>> so thatgeneric RISC-V can easily reuse the loader code. Thus, the
> >first patch
> >> >>> just moves the ARM64 code to common code. I have compile tested
> >for
> >> >>> ARM64/ARM32. Even though it doesn't introduce any functional
> >change
> >> >>> for ARM/ARM64, any real testing will be helpful.
> >> >>
> >> >> May I suggest that we not blindly adopt the ARM code here, but
> >> >> instead, use the new initrd loading protocol that removes the need
> >for
> >> >> GRUB to modify or even know about the device tree at all?
> >>
> >> Does this protocol exist in EDK2 by now?
> >>
> >
> >Yes. It exists as a shell command, and as a load option for OVMF.
> >
> >> In U-Boot there is a basic implementation which can provide a single
> >> initrd image with a hardcoded file name. The file_path argument
> >passed
> >> to U-Boot is ignored due to Ilias' security concerns when he wrote
> >the
> >> patch.
> >>
> >> GRUB is only needed if we have multiple kernels to choose from with
> >> distinct initial ramdisks.
> >>
> >> Please, describe what you expect the initrd loading protocol to do
> >when
> >> called from GRUB. How will the ramdisk fitting the kernel chosen in
> >GRUB
> >> be identified?
> >>
> >
> >The same what GRUB's 'initrd' command does. Whichever initrd you
> >select with it is the one that gets returned by the protocol.
>
> Will GRUB provide the absolute device path in parameter file_path?
>

Which parameter 'file_path" is that?