Messages in this thread | | | Date | Tue, 1 Sep 2009 23:17:20 +0800 | From | Américo Wang <> | Subject | Re: [RFC][PATCH] x86: introduce parse_early_param_alone() to parse param early (Was Re: linux-next: reservetop fix disables mem= ) |
| |
On Tue, Sep 01, 2009 at 03:55:14PM +0800, Xiao Guangrong wrote: >Hi Ingo, > >I find the broken patch is still in -tip tree: > >Commit-ID: 8126dec32738421afa362114337331337b4be17f >Gitweb: http://git.kernel.org/tip/8126dec32738421afa362114337331337b4be17f >Author: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> >AuthorDate: Thu, 20 Aug 2009 20:23:11 +0800 >Committer: Ingo Molnar <mingo@elte.hu> >CommitDate: Fri, 21 Aug 2009 16:40:30 +0200 > >x86: Fix system crash when loading with "reservetop" parameter > >So, this patch is base on it. >--------------------------------------------- >Subject: [RFC][PATCH] x86: introduce parse_early_param_alone() to parse param before parse_early_param() > >Sometimes, we should parse specific boot parameter alone before >parse_early_param(), such as "reservetop" and "early_ioremap_debug", >like below: > >> The main problem is that can't parse 'reservetop' and 'mem'/'memmap' >> parameters at the same time, because we should parse 'mem'/'memmap' >> after e820 map detected, and it might use early_memremap() during >> e820 map detecting, so we should call early_ioremap_init() before it, >> 'reservetop' parameter can change 'FIXADDR_TOP', so we parse >> 'reservetop' first, >> >> like below sequences: >> ...... >> ___parse 'reservetop'___ -> >> early_ioremap_init() -> >> setup_memory_map(); /* might call early_memremap()*/ -> >> parse_setup_data(); /* might call early_memremap()*/ -> >> e820_reserve_setup_data(); -> >> ___parse 'mem'/'memmap' and other parameters___ >> ...... >> >> (the same as 'early_ioremap_debug' parameter) >> >> So, I'm afraid that we need separate parse 'reservetop'/ >> 'early_ioremap_debug' parameters early >> > >This patch introduce a new api named parse_early_param_alone() to >do this. > >Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> >--- > arch/x86/kernel/setup.c | 33 ++++++++++++++++++------------ > include/linux/init.h | 1 + > init/main.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 71 insertions(+), 13 deletions(-) > >diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c >index 83ea092..f241c12 100644 >--- a/arch/x86/kernel/setup.c >+++ b/arch/x86/kernel/setup.c >@@ -696,10 +696,28 @@ void __init setup_arch(char **cmdline_p) > printk(KERN_INFO "Command line: %s\n", boot_command_line); > #endif > >+#ifdef CONFIG_CMDLINE_BOOL >+#ifdef CONFIG_CMDLINE_OVERRIDE >+ strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE); >+#else >+ if (builtin_cmdline[0]) { >+ /* append boot loader cmdline to builtin */ >+ strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE); >+ strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE); >+ strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE); >+ } >+#endif >+#endif
This seems ugly.
CMDLINE_OVERRIDE depends on CMDLINE_BOOL, right? So the outer #ifdef can be removed. :)
-- Live like a child, think like the god.
| |