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

["Huang, Ying" <ying.huang@intel.com>]

On Mon, 2007-08-20 at 20:54 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> > 
> > I think the "next" field can be u32 instead of u64. Because the linked
> > list of struct setup_data is prepared by bootloader, which can control
> > the memory location.
> > 
> 
> That's making some pretty serious assumptions on future boot loaders and
> environments.

I think this assumption is reasonable. The range of u32 is big enough
for a boot protocol. Do we need to convert that to u128, when 128-bit
machine emerges?

I think there is another possible scheme. An array with variable length
element instead of a linked list can be used too. The type of element is
as follow:

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

The next element is at (char *)&setup_data + len. The boot information
will be held in a block of memory. This makes initial memory mapping of
kernel more easily. And the memory location of boot information may need
to be kept in a limited range too.

> > As for the magic number in zero page, do you think it should be used
> > only by 16-bit kernel setup code?
> 
> Absolutely not.

If a old boot loader (not aware of magic number) is used to load the new
kernel image. The old boot loader will set the magic number to zero.
Does this mean that the new kernel image can not be booted by the old
boot loader.

Best Regards,
Huang Ying
-
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/