On Wed, 2013-01-23 at 16:26 +0000, Matt Fleming wrote:
> It's worth pointing out that efilinux doesn't invoke the handover
> protocol as a function, it pushes arguments onto the stack and jumps.
> So this change will actually break that boot loader.
>
> Is there a particular reason why you need to invoke it as a standard
> function on 32-bits?
Oh, for fuck's sake. It's clearly documented as a *FUNCTION* in
Documentation/x86/boot.txt:
>>>>>>>>>>>>>>.
The function prototype for the handover entry point looks like this,
efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp)
<<<<<<<<<<<<<<
This whole thing is a complete clusterfuck. To recap just *some* of the
more egregious parts of the breakage:
- We put the handover_offset field into kernels with !CONFIG_EFI_STUB.
- We have a magical 0x200 delta for handover_offset on a 64-bit kernel.
- We don't *indicate* which kernels are 64-bit and which are 32-bit,
which means that not only does the bootloader not know whether to
add that brain-dead magical 0x200 offset, it *also* doesn't know which
mode the CPU needs to be in (and which wordsize of EFI needs to be
supported by the system).
Quite frankly, anything trying to invoke the EFI boot stub right now is
broken. Actually broken in the "it doesn't boot" sense, for at least 50%
of kernels. Anybody looking at incorporating bootloader support for it
should have done what I did, and throw their hands up in horror and
*fix* it before they could consider using it.
How about we write off the existing handover_offset field and consider
it a failed experiment in psychotic drugs, then introduce a *new* one
with sane and documented semantics? Hell, it only needs to be one byte
(handover_offset >> 4) rather than a whole four bytes....
--
dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
