From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751096Ab2KYFxK (ORCPT ); Sun, 25 Nov 2012 00:53:10 -0500 Received: from terminus.zytor.com ([198.137.202.10]:45601 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750768Ab2KYFxJ (ORCPT ); Sun, 25 Nov 2012 00:53:09 -0500 User-Agent: K-9 Mail for Android In-Reply-To: References: <1353482170-10160-1-git-send-email-yinghai@kernel.org> <1353482170-10160-12-git-send-email-yinghai@kernel.org> <50AD0CA1.8000904@zytor.com> <50AD291A.10600@zytor.com> <50AE70E7.6060204@zytor.com> <87haofi3d3.fsf@xmission.com> <50B104BC.90208@zytor.com> <50B124E9.400@zytor.com> <87vccud0i5.fsf@xmission.com> <50B16080.7040809@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PATCH v3 11/12] x86, boot: add fields to support load bzImage and ramdisk high From: "H. Peter Anvin" Date: Sat, 24 Nov 2012 21:52:11 -0800 To: Yinghai Lu CC: "Eric W. Biederman" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, Rob Landley , Matt Fleming Message-ID: <46262b07-80f0-48ab-a0a2-0b8a9a21c726@email.android.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org But it doesn't solve the bigger problem, and it is just begging to be gotten wrong. Yinghai Lu wrote: >On Sat, Nov 24, 2012 at 4:11 PM, Yinghai Lu wrote: >> On Sat, Nov 24, 2012 at 4:04 PM, H. Peter Anvin >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.