On 6/16/23 16:15, Matthew Garrett wrote:
On Fri, Jun 16, 2023 at 04:01:09PM -0400, Daniel P. Smith wrote:
On 5/15/23 21:43, Matthew Garrett wrote:
On Mon, May 15, 2023 at 08:41:00PM -0400, Daniel P. Smith wrote:
On 5/15/23 17:22, Matthew Garrett wrote:
What if I don't use grub, but use something that behaves equivalently?
Which value should be used here?
Generally we would request that the bootloader submit a request to register
for a value to be reserved in the spec. That aside, the intent here is to
allow for the possibility for the DLE handler to be independent from the
bootloader, but this does not have to be this way. If a non-open entity
decides to produce their own implementation, they can freely use a
unallocated value at their own risk that it could be allocated to another
bootloader in the future. Though in this scenario it likely would not matter
as the non-open DLE handler would only be present when the non-open
bootloader was present.
Is the expectation that the DLE will always be shipped with the
bootloader? I think I'm not entirely clear on what's consuming this and
why.
No, in fact, an early idea proposed by a pair of us in the TrenchBoot
community was to have it live either as a Runtime Service that was loaded by
a UEFI app or in the coreboot UEFI payload.
Ok, then I think I'm still confused. If I want to write a new bootloader
but make use of the existing DLE, what contract am I establishing and
what value should I be putting in here?
Apologies on the delayed response, vacation and what not.
I believe I know where the confusion is coming from, let me see if I can
explain better by why that field came about. The motivation for the SLRT
came out of our agreement to use a callback mechanism to support
entering efi-stub and then going back to a dynamic launch aware hook to
complete the initiation of the dynamic launch. The SLRT was devised as a
platform and kernel agnostic means to handle the launch. As such, there
was a desire to use that interface, and the underlying DLE code, whether
GRUB was launching the kernel via the UEFI interface or the traditional
interface. Skipping the details, but it boils down to the fact that in
the non-UEFI case, functionality from core GRUB was needed. As a result,
to provide maximum flexibility for other bootloaders, and to make it
easier on us, we add the ability to pass a context object across the
interface. Thus allowing GRUB's DLE handler to have a single entry that
could be called externally by efi-stub or directly from GRUB proper.
IOW, the bootloader context is a means to provide a bootloader with them
means to implement a private interface between the bootloader proper and
a DLE handler that it installed into memory should its implementation
require it.
There is an underlying question within your question, and that is of
reuse. In this case, we wrote GRUB's DLE handler was written
specifically to be used by GRUB. It was written to provide a stable and
demonstrable implementation of the SL interface. In the future it may
get refactored or a common standalone implementation, e.g., the
previously mentioned UEFI runtime service, may arise that would be
reusable by multiple bootloaders.
I hope this helped explain the purpose and use of this area of the
table. Please let me know if it did not.
V/r,
DPS
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
