Re: [PATCH 0/3] x86_64 EFI runtime service support

["H. Peter Anvin" <hpa@zytor.com>]

Huang, Ying wrote:
>>
>> Has the zero page documentation and version numbering project
>> made any progress? I think we cannot merge this without at least
>> the version number
> 

More than that.  You need to be able to boot a 32-bit kernel on a 64-bit
system, so anything that breaks that is a nonstarter.  Of course, if EFI
itself inherently breaks that, then, well, that's just another reason to
avoid EFI like the plague, but I can't think that even EFI is that broken.

> OK, I will work on the zero page documentation and version numbering
> project.

There already is documentation (Documentation/i386/zero-page.txt); as
far as version numbering, that means sticking in a field with a number,
and adding a magic number (since there isn't anything that guarantees
that fields are otherwise zero.)

Anything that conforms to the updated standard should guarantee
undefined fields are zero.

However, we also have an immediate need to define how to grow past 4K,
and if we're going to have a major revision in mechanism I would like to
see that happen now.

I propose that, in addition to the aforementioned version number and
magic fields, we add a pointer, which should be the last pointer added
that doesn't point into I/O space or reserved memory (i.e. memory that
is off limit anyway for the operating system.)

This pointer should point to a linked list of suggested form:

struct setup_data {
	u64 next;
	u32 type;
	u32 len;
	u8 data[];
};

This can thus encapsulate large objects as necessary, and the early
kernel entry can linearize them if it needs to move them out of the way.
 Better yet, this information can be made available to sysfs for
debuggability, and/or use by kexec.

I haven't heard anything from the kexec people on this, and they are the
main users of the PM entrypoint as far as I can tell.

Also, is there a maintainer for 32-bit EFI?

	-hpa


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