But it doesn't solve the bigger problem, and it is just begging to be gotten wrong.
Yinghai Lu <ying...@kernel.org> wrote: >On Sat, Nov 24, 2012 at 4:11 PM, Yinghai Lu <ying...@kernel.org> wrote: >> On Sat, Nov 24, 2012 at 4:04 PM, H. Peter Anvin <h...@zytor.com> >wrote: >>> >>> It sounds like we are leaning toward some form of the sentinel hack, >which >>> means we need an enumerated list of things that should *not* be >zeroed if >>> the sentinel is present. >>> >>> The option of declaring the list frozen makes me a bit nervous, >because it >>> isn't clear that we don't already have fields that will be >misinterpreted by >>> the kernel if filled in from the file. >> >> USE_EXT_BOOT_PARAMS bit in xloadflags should work. > >new kexec will clean around bit around setup head, and set that bit, >if it is not with real_mode entry. > >32bit and 64bit entry: >old kernel has no idea of this bit, and still use old ramdisk_image, >cmd_line_ptr in setup header. >new kernel will check that bit before it use ext_ramdisk_image, and >ext_cmd_line_ptr. > >old kexec and new kernel is safe too, because that bit is not set, new >kernel will not use ex_... > >later all new kernel need to check USE_EXT_BOOT_PARAMS bit for all new >added field in boot_params. -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- 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/
