Re: [PATCH v4] templates: introduce GRUB_TOP_LEVEL_* vars

2022-10-18 Thread Olaf Hering
Mon, 17 Oct 2022 03:35:32 -0700 Denton Liu : > A user may wish to use an image that is not sorted as the "latest" > version as the top-level entry. Correct. What is really required is some form of file pattern matching and to use --id= in "menuentry title" commands. That way one can have the

Re: [PATCH v4] templates: introduce GRUB_TOP_LEVEL_* vars

2022-10-18 Thread Denton Liu
Hi Olaf, On Tue, Oct 18, 2022 at 01:12:35PM +0200, Olaf Hering wrote: > Mon, 17 Oct 2022 03:35:32 -0700 Denton Liu : > > > A user may wish to use an image that is not sorted as the "latest" > > version as the top-level entry. > > Correct. > > What is really required is some form of file patter

Re: [PATCH v4] templates: introduce GRUB_TOP_LEVEL_* vars

2022-10-18 Thread Olaf Hering
Tue, 18 Oct 2022 06:57:36 -0700 Denton Liu : > If I'm understanding correctly, what you're proposing is a mechanism for > setting the default entry. If I'm not mistaken, this seems like an > orthogonal discussion to me. My patch proposes a method of setting the > top-level menu entry while this me

[PATCH v5 0/6] linux: implement LoadFile2 initrd loading

2022-10-18 Thread Ard Biesheuvel
This implements the LoadFile2 initrd loading protocol, which is essentially a callback interface into the bootloader to load the initrd data into a caller provided buffer. This means the bootloader no longer has to contain any policy regarding where to load the initrd (which differs between archite

[PATCH v5 6/6] linux: ignore FDT unless we need to modify it

2022-10-18 Thread Ard Biesheuvel
Now that we implemented support for the LoadFile2 protocol for initrd loading, there is no longer a need to pass the initrd parameters via the device tree. This means that when the LoadFile2 protocol is being used, there is no reason to update the device tree in the first place, and so we can ignor

[PATCH v5 2/6] linux/arm: unify ARM/arm64 vs Xen PE/COFF header handling

2022-10-18 Thread Ard Biesheuvel
Xen has its own version of the image header, to account for the additional PE/COFF header fields. Since we are adding references to those in the shared EFI loader code, update the common definitions and drop the Xen specific one which no longer has a purpose. Since in both cases, the call to grub_

[PATCH v5 3/6] linux/arm: account for COFF headers appearing at unexpected offsets

2022-10-18 Thread Ard Biesheuvel
The way we load the Linux and PE/COFF image headers depends on a fixed placement of the COFF header at offset 0x40 into the file. This is a reasonable default, given that this is where Linux emits it today. However, in order to comply with the PE/COFF spec, which allows this header to appear anywhe

[PATCH v5 4/6] efi/efinet: Don't close connections at fini_hw() time

2022-10-18 Thread Ard Biesheuvel
When GRUB runs on top of EFI firmware, it only has access to block and network device abstractions exposed by the firmware, and it is up to the firmware to quiesce the underlying hardware when exiting boot services and handing over to the OS. This is especially important for network devices, to pr

[PATCH v5 1/6] efi: move MS-DOS stub out of generic PE header definition

2022-10-18 Thread Ard Biesheuvel
The PE/COFF spec permits the COFF signature and file header to appear anywhere in the file, and the actual offset is recorded in 4 byte little endian field at offset 0x3c of the image. When GRUB is emitted as a PE/COFF binary, we reuse the 128 byte MS-DOS stub (even for non-x86 architectures), put

[PATCH v5 5/6] efi: implement LoadFile2 initrd loading protocol for Linux

2022-10-18 Thread Ard Biesheuvel
Recent Linux kernels will invoke the LoadFile2 protocol installed on a well-known vendor media path to load the initrd if it is exposed by the firmware. Using this method is preferred for two reasons: - the Linux kernel is in charge of allocating the memory, and so it can implement any placement

Re: [PATCH v4 1/1] Add support for grub-emu to kexec Linux menu entries

2022-10-18 Thread Robbie Harwood
Oskari Pirhonen writes: > On Tue, Oct 04, 2022 at 15:16:48 -0400, Robbie Harwood wrote: >> From: Raymund Will >> >> The GRUB emulator is used as a debugging utility but it could also be >> used as a user-space bootloader if there is support to boot an operating >> system. >> >> The Linux kerne

Re: [PATCH v4] templates: introduce GRUB_TOP_LEVEL_* vars

2022-10-18 Thread Denton Liu
Hi Olaf, On Tue, Oct 18, 2022 at 04:18:21PM +0200, Olaf Hering wrote: > I think this can be done already today. At least YaST offers a way to select > a specific item in a submenu and pass it to grub-set-default. This leads to > an entry like this in grubenv: Right, we currently offer the abili

Re: [PATCH v4] templates: introduce GRUB_TOP_LEVEL_* vars

2022-10-18 Thread Michael Chang via Grub-devel
On Tue, Oct 18, 2022 at 04:18:21PM +0200, Olaf Hering wrote: > Tue, 18 Oct 2022 06:57:36 -0700 Denton Liu : > > > If I'm understanding correctly, what you're proposing is a mechanism for > > setting the default entry. If I'm not mistaken, this seems like an > > orthogonal discussion to me. My patc