Re: [PATCH v6 06/12] efi: Use the same filename for all sandbox builds

[Heinrich Schuchardt]

Am 18. Oktober 2024 05:05:08 MESZ schrieb Simon Glass <sjg at chromium.org>:
>Hi Tom,
>
>On Thu, 17 Oct 2024 at 18:17, Tom Rini <trini at konsulko.com> wrote:
>>
>> On Thu, Oct 17, 2024 at 05:23:19PM -0600, Simon Glass wrote:
>> > Hi Heinrich,
>> >
>> > On Mon, 30 Sept 2024 at 17:23, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>> > >
>> > > On 26.09.24 23:59, Simon Glass wrote:
>> > > > Sandbox is not a real architecture, but within U-Boot it is real enough.
>> > > > We should not need to pretend it is x86 or ARM anywhere in the code.
>> > > >
>> > > > Also we want to be able to locate the sandbox app using a single
>> > > > filename, 'bootsbox.efi', to avoid needing tests to produce different
>> > > > files on each host architecture.
>> > > >
>> > > > Drop the confusing use of host architecture and just let sandbox be
>> > > > sandbox.
>> > >
>> > > As I already wrote in
>> > > https://lore.kernel.org/u-boot/ae1cf1fa-766e-46a0-8ef9-2c2c7af73d9e@gmx.de/
>> > > this patch should not be merged.
>> > >
>> > > bootsbx.efi does not exist in the UEFI specification.
>> >
>> > If that is of concern I can get it added. Let me know.
>> >
>> > >
>> > > Without this patch I can test that shim work and grub are correctly
>> > > loaded from a distro image. This patch makes the sandbox misbehave.
>> >
>> > Why don't you do that with QEMU?
>> >
>> > If we want sandbox to do this, I could add a way for sandbox to select
>> > its architecture. But this patch is correct, sorry. It is basically a
>> > revert of your patch:
>> >
>> > 3a0654ecd0d efi_loader: correctly identify binary name
>> >
>> > Let me know if you would like a selection mechanism and I'll see what I can do.
>>
>> I'm confused. It sounds like Heinrich is using sandbox to test on
>> various hosts, how U-Boot behaves, without relying on "just test in
>> QEMU". I don't see how this disconnects from your usual request on how
>> to use sandbox for further testing. What is breaking for you, Simon, by
>> us saying that the host instruction set determines what we load and run
>> (and so, is portable whereas saying "sandbox" is not, between x86 hosts,
>> arm64 hosts and riscv64 hosts).
>
>This:
>
>Also we want to be able to locate the sandbox app using a single
>filename, 'bootsbox.efi', to avoid needing tests to produce different
>files on each host architecture.

As I wrote before: 

The UEFI specification prescribes the naming of the default boot binary. Deviating from the specification should be avoided.

Anyway you need different images per host architecture. Writing a single switch statement to derive the default EFI binary name from the OS architecture does not look like an undue burden.

The sandbox should remain able to start GRUB from a distro image for the host architecture.

The sandbox is not a fake architecture but can be considered a valid testbed for host native EFI binaries including GRUB, the kernel stub, the stubs of UKI images, and the EFI SCT.

Best regards

Heinrich


>
>The idea of using sandbox to run native EFI apps is new to me, but it
>sounds great, if it will get us more tests in this area.
>
>But sandbox is sandbox. It is not (x86, arm, riscv). It is a fake
>architecture that we use in U-Boot. I've offered to create a way to
>get the behaviour that Heinrich wants, so let's see what he says.
>
>Regards,
>Simon