RE: [UPDATED PATCH] EFI support for ia32 kernels

[Tolentino, Matthew E]

> Getting EFI drivers in a byte code format would of course be nice.
> But mostly this helps the Itanium, not x86.  I can already get
> standard x86 option roms.

It would be nice.  It is especially nice for vendors because they can reuse a single driver image for multiple architectures assuming there is an interpreter and EFI support.  

> I totally agree that it is reasonable to bypass setup.S.  But 
> to do that reliably requires consensus that the 32bit entry point is 
> stable.  That has not happen yet, and your patch did nothing to address that.  I
> know it has to happen because I know the boot process, and what has to
> happen to boot with a different x86 BIOS implementation.

Ok, so how do we know it is stable and how might one address that?  How have you addressed this with kexec?  

> Entering via the 32bit entry point has not been previously discussed.
> H. Petern Anvin has not been convinced it should be a stable kernel
> entry point.  

Why?  I've missed this argument.   

The documentation has not been updated.  A recent RedHat
> kernel has even shipped with a different 32bit kernel entry point.

I'm afraid I haven't looked at kexec.  Do you employ the standard 32 bit entry point or do you actually go back to real mode or something in between?

> My hunch is that most of the EFI code should actually live in another
> subarch.  I think the kernel has support for compiling in multiple
> subarches.  If not it is simply because no one has gotten 
> that far yet.

I can see how this could be useful and potentially consolidate the efi related code in ia64, the ia32 stuff I've posted, and any other architecture that supports efi in the future, but don't know about compiling in multiple subarchs.  Comments on how this is done?  

matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/