On 12/12/2012 06:49 PM, Yinghai Lu wrote:
Hi, Peter,
What's your decision about this?
Do you mean have one boot_params mask in initdata and AND that with
boot_params from bootloader
to clean not used bytes?
So later will not need to check
if (boot_params.hdr.xloadflags & USE_EXT_BOOT_PARAMS)
?
I worked out other patches that remove kdump 896M limitation.
would like to post those patches to get more testing.
those are needed for bigger system with lots of pcie devices.
ping!
I still want to do what I mentioned before, because we need to not rely
on the initialized/16-bit portion so much:
1. add a field in the uninitialized portion, call it "sentinel";
2. make sure the byte position corresponding to the "sentinel" field is
nonzero in the bzImage file;
3. if the kernel boots up and sentinel is nonzero, erase those fields
that you identified as uninitialized;
4. assign a proper boot loader ID to kexec, so we have a way of dealing
with this kind of debacles in the future (that is what the
bootloader ID is for: it gives us a way to work around
bootloader-specific problems.)
We also need to formalize the 64-bit entry point properly, including all
the entry conditions and so forth. That needs to be documented.
Eric, any thoughts or additional opinions?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
