On Mon, 2007-08-20 at 10:12 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> >>
> >> 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[];
> >> };
> >>
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.
To facilitate the kernel early mapping, I think the memory location of
"linked list" should be kept to a predefined range (in the real mode
memory area?).
> > So, we need not define a new boot protocol, just extend the standard
> > boot protocol. The version number and magic need not to be added to
> > "zero page". But, at the same time, the bootloader on EFI, LinuxBIOS and
> > kexec must be changed accordingly.
> >
>
> I think this is too radical of a change to be practical. Instead, I
> propose the following:
>
> - "struct boot_params" (the zeropage) is kept as a legacy interface.
> %esi will continue to point to it on entry to the 32-bit entrypoint
> (presumably that is %rsi on entry to a 64-bit entrypoint?)
>
> - We add a magic number and a pointer chain to the zeropage. The
> presence of the magic number indicates that:
>
> - Any unused fields in the zeropage is zero;
> - The pointer chain is valid (unless zero);
> - The old "HD info" fields (and possibly the EDD fields)
> can be recycled.
Previously, I think the "zero page" is not external formally, so we can
ignore the user. But it is used by some bootloaders. So your proposal
may be better, especially for these bootloaders.
I think something others need to be done:
- Increase the version number of standard boot protocol.
- Add the contents of zero page into standard boot protocol document as
a optional part for 32-bit entry (and 64-bit entry?).
- Make 32-bit (64-bit?) boot protocol formal in standard boot protocol
document.
> What a post-upgrade kernel should do upon encountering an old structure
> (sans magic) is to zero out any fields that wasn't present in the legacy
> structure definition, including the pointer chain, then it can use it as-is.
As for the magic number in zero page, do you think it should be used
only by 16-bit kernel setup code?
> We should avoid adding fields to the zero_page after that, unless
> necessary for backwards compatibility reasons. In general, new data
> items should be added as pointer capabilities.
Yes.
> Compare this to the legacy PCI header vs. PCI capabilities.
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
