Hi all,
In Linus' tree, today's linux-next build (x86_84 allmodconfig) produced
this warning:
arch/x86/kernel/process.c: In function 'idle_setup':
arch/x86/kernel/process.c:645:1: warning: unknown escape sequence: '\i'
Introduced by commit 5d4c47e0195b ("x86 idle: deprecate mwait_idle() and
"idle=mwait" cmdline param").
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
From: Len Brown <[email protected]>
Date: Sun, 29 May 2011 23:38:15 -0400
Subject: [PATCH] x86 idle: fix build warning for WARN_ONCE("idle=mwait")
In 5d4c47e0195b989f284907358bd5c268a44b91c7
"x86 idle: deprecate mwait_idle() and "idle=mwait" cmdline param"...
I fat-fingered the editing when I updated the WARN_ONCE() string:
arch/x86/kernel/process.c: In function 'idle_setup':
arch/x86/kernel/process.c:645:1: warning: unknown escape sequence: '\i'
remove the '\n' while we are here, it works fine without it.
Signed-off-by: Len Brown <[email protected]>
---
arch/x86/kernel/process.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 426a5b6..c54f87d 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -642,7 +642,7 @@ static int __init idle_setup(char *str)
boot_option_idle_override = IDLE_POLL;
} else if (!strcmp(str, "mwait")) {
boot_option_idle_override = IDLE_FORCE_MWAIT;
- WARN_ONCE(1, "\idle=mwait\" will be removed in 2012\"\n");
+ WARN_ONCE(1, "\"idle=mwait\" will be removed in 2012");
} else if (!strcmp(str, "halt")) {
/*
* When the boot option of idle=halt is added, halt is
--
1.7.4.4
* Len Brown <[email protected]> wrote:
> From: Len Brown <[email protected]>
> Date: Sun, 29 May 2011 23:38:15 -0400
> Subject: [PATCH] x86 idle: fix build warning for WARN_ONCE("idle=mwait")
>
> In 5d4c47e0195b989f284907358bd5c268a44b91c7
> "x86 idle: deprecate mwait_idle() and "idle=mwait" cmdline param"...
>
> I fat-fingered the editing when I updated the WARN_ONCE() string:
>
> arch/x86/kernel/process.c: In function 'idle_setup':
> arch/x86/kernel/process.c:645:1: warning: unknown escape sequence: '\i'
>
> remove the '\n' while we are here, it works fine without it.
>
> Signed-off-by: Len Brown <[email protected]>
> ---
> arch/x86/kernel/process.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Len, i'd *really* prefer it if patches changing arch/x86/ had a
longer test time in linux-next than what you are gave it here.
This kind of 'send them to lkml and merge them into your linux-next
branch and send it to Linus on the same day' kind of ambush you have
done with the 'x86 idle' patches might be convenient to you, but it
is inconvenient to pretty much anyone else - and it is absolutely
unacceptable to us x86 maintainers ...
*Especially* as these patches were contentious when you last posted
them as an RFC to lkml ...
So please watch out for this in the future, ok?
Thanks,
Ingo
> Len, i'd *really* prefer it if patches changing arch/x86/ had a
> longer test time in linux-next than what you are gave it here.
I agree 100%, and I will do better in the future.
This was very difficult timing for a merge window for me.
> these patches were contentious when you last posted
> them as an RFC to lkml ...
The idle cleanup patches were contentious when I posed them
because my original proposal deleted a bunch of code right away.
Alan convinced me that the community doesn't move that fast,
and that we should wallow in the swill for a while longer before
deleting. Others volunteered to test the latest upstream kernel
on APM hardware, giving APM's presence in the upstream kernel a life line.
So all I did was add the recommended feature-removal's and warnings
for the stuff which obviously should go. But if you see some of
your favorite bits on the chopping block, you have at least
6 months to make a case for them:-)
thanks,
-Len
* Brown, Len <[email protected]> wrote:
> Alan convinced me that the community doesn't move that fast, and
> that we should wallow in the swill for a while longer before
> deleting. [...]
Yeah, it's much nicer this way.
> [...] Others volunteered to test the latest upstream kernel on APM
> hardware, giving APM's presence in the upstream kernel a life line.
> So all I did was add the recommended feature-removal's and warnings
> for the stuff which obviously should go. But if you see some of
> your favorite bits on the chopping block, you have at least 6
> months to make a case for them :-)
:-)
I only saw one of the runtime warnings on one of my testboxes - i
adjusted the boot parameter setting (the parameter was bogus) and
moved on. So life can go on as far as i'm involved :-)
Thanks,
Ingo