From: "H. Peter Anvin" <hpa@zytor.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: fengguang.wu@intel.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org,
HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
bp@alien8.de, ebiederm@xmission.com, akpm@linux-foundation.org,
hpa@linux.intel.com, jingbai.ma@hp.com
Subject: Re: [RESEND PATCH v10] x86, apic, kexec, Documentation: Add disable_cpu_apicid kernel parameter
Date: Wed, 15 Jan 2014 10:20:28 -0800 [thread overview]
Message-ID: <52D6D16C.8060207@zytor.com> (raw)
In-Reply-To: <20140115181426.GC29244@redhat.com>
On 01/15/2014 10:14 AM, Vivek Goyal wrote:
>
> For large amount of info like memory map, I agree that passing on command
> line is not a good idea. (/me taks the blame for doing that). That's why
> in new patches I want to move to pass new map on bootparams and pass
> saved_max_pfn on command line instead. This is a fresh start so we
> probably can ignore compatibility with older kernels for this new
> interface and set things right.
>
> But for smaller options, command line seems to be good that they don't
> consume precious space in bootparams. If we introduce an option today,
> we are not sure if kdump will continue to use that option down the line
> or not. For example, few years down the line, we might be able to send
> INIT IPI to boot cpu too and not need disable_cpu_apicid. Same is the case
> with max_cpus vs nr_cpus. We used to use max_cpus=1 and now use nr_cpus=1.
> If we put all this informatoin in bootparams, they might soon become
> obsolete and keep on sitting there for eternity with no users.
>
> Also by creating a command line, a user can use these knobs as debugging
> options and can easily test first kernel's behavior to make sure knob
> works well in first kernel before it is tested in second kernel. By making
> it part of bootparams, we have no idea whether knob works fine in first
> kernel or not.
>
> For above reasons, I am not averse to the idea of commingling.
>
bootparams is not a precious resource, and even if it was, you could
create your own (kexec) structure and put it in the boot_info linked
list. bootparams is not a precious resource because is is actually
rather straightforward to extend past 4K should it become necessary; all
we really would need to do there is to include a length field in the
structure. An auxiliary bootparams structure is also a possibility.
-hpa
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
hpa@linux.intel.com, jingbai.ma@hp.com,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
bp@alien8.de, ebiederm@xmission.com, akpm@linux-foundation.org,
fengguang.wu@intel.com
Subject: Re: [RESEND PATCH v10] x86, apic, kexec, Documentation: Add disable_cpu_apicid kernel parameter
Date: Wed, 15 Jan 2014 10:20:28 -0800 [thread overview]
Message-ID: <52D6D16C.8060207@zytor.com> (raw)
In-Reply-To: <20140115181426.GC29244@redhat.com>
On 01/15/2014 10:14 AM, Vivek Goyal wrote:
>
> For large amount of info like memory map, I agree that passing on command
> line is not a good idea. (/me taks the blame for doing that). That's why
> in new patches I want to move to pass new map on bootparams and pass
> saved_max_pfn on command line instead. This is a fresh start so we
> probably can ignore compatibility with older kernels for this new
> interface and set things right.
>
> But for smaller options, command line seems to be good that they don't
> consume precious space in bootparams. If we introduce an option today,
> we are not sure if kdump will continue to use that option down the line
> or not. For example, few years down the line, we might be able to send
> INIT IPI to boot cpu too and not need disable_cpu_apicid. Same is the case
> with max_cpus vs nr_cpus. We used to use max_cpus=1 and now use nr_cpus=1.
> If we put all this informatoin in bootparams, they might soon become
> obsolete and keep on sitting there for eternity with no users.
>
> Also by creating a command line, a user can use these knobs as debugging
> options and can easily test first kernel's behavior to make sure knob
> works well in first kernel before it is tested in second kernel. By making
> it part of bootparams, we have no idea whether knob works fine in first
> kernel or not.
>
> For above reasons, I am not averse to the idea of commingling.
>
bootparams is not a precious resource, and even if it was, you could
create your own (kexec) structure and put it in the boot_info linked
list. bootparams is not a precious resource because is is actually
rather straightforward to extend past 4K should it become necessary; all
we really would need to do there is to include a length field in the
structure. An auxiliary bootparams structure is also a possibility.
-hpa
next prev parent reply other threads:[~2014-01-15 18:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-15 6:44 [RESEND PATCH v10] x86, apic, kexec, Documentation: Add disable_cpu_apicid kernel parameter HATAYAMA Daisuke
2014-01-15 6:44 ` HATAYAMA Daisuke
2014-01-15 17:05 ` Vivek Goyal
2014-01-15 17:05 ` Vivek Goyal
2014-01-15 17:26 ` H. Peter Anvin
2014-01-15 17:26 ` H. Peter Anvin
2014-01-15 17:47 ` Vivek Goyal
2014-01-15 17:47 ` Vivek Goyal
2014-01-15 17:54 ` H. Peter Anvin
2014-01-15 17:54 ` H. Peter Anvin
2014-01-15 18:14 ` Vivek Goyal
2014-01-15 18:14 ` Vivek Goyal
2014-01-15 18:20 ` H. Peter Anvin [this message]
2014-01-15 18:20 ` H. Peter Anvin
2014-02-10 17:28 ` Petr Tesarik
2014-02-10 17:28 ` Petr Tesarik
2014-01-15 17:57 ` [tip:x86/apic] x86, apic, kexec: " tip-bot for HATAYAMA Daisuke
2014-01-15 18:25 ` Ingo Molnar
2014-01-15 21:09 ` [tip:x86/apic] x86, apic: Make disabled_cpu_apicid static read_mostly, fix typos tip-bot for H. Peter Anvin
2014-01-16 4:44 ` HATAYAMA Daisuke
2014-01-16 5:53 ` H. Peter Anvin
2014-01-16 6:20 ` HATAYAMA Daisuke
2014-01-16 6:24 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52D6D16C.8060207@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=d.hatayama@jp.fujitsu.com \
--cc=ebiederm@xmission.com \
--cc=fengguang.wu@intel.com \
--cc=hpa@linux.intel.com \
--cc=jingbai.ma@hp.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.