On Mon, 2013-01-07 at 19:16 +0000, Matthew Garrett wrote: > On Mon, Jan 07, 2013 at 07:12:51PM +0000, David Woodhouse wrote: > > On Mon, 2013-01-07 at 18:43 +0000, Matthew Garrett wrote: > > > The kernel does, the EFI boot stub doesn't. There's probably an argument > > > for having it fail in that case, but it wouldn't even be able to print > > > an error message without some gymnastics. > > > > Printing an error message is simple enough from assembler; you just need > > to call sys_table->con_out->output_string. > > I don't think that's guaranteed to do something unless we've set a > console mode first, but sure, that ought to be an improvement. It's what we do for efi_printk() in all other cases where the EFI stub bails out. It's certainly fair enough as a best-effort. > > "Sorry, this kernel cannot boot in " (32|64) "-bit mode this way. Your > > bootloader should have ignored the shiny new EFI handover protocol and > > booted it the old way. It would have worked then, albeit without EFI > > runtime services. Which you probably wouldn't have missed." > > "(32|64) bit kernels cannot be booted via the EFI handover > protocol on (64|32) bit firmware"? Yeah. But the bootloader *could* have booted this kernel, if it had just chosen to use the old handover protocol. And right now, there's no way for the bootloader to *tell* what it should do. It wouldn't be impossible to simply have both 32-bit and 64-bit stubs (conditionally) present in the kernel, and support both simultaneously. But if we can't do that, then I suspect we should at *least* make sure we let the bootloader know which one *is* available, so it doesn't end up calling the wrong one. Perhaps we should declare that handover_offset is for the 64-bit stub, and add a handover_offset32 for the 32-bit stub? -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
