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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/