twitter: linux.kernel - 23 new messages in 13 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* sched: restore sanity - 10 messages, 4 authors
http://groups.google.com/group/linux.kernel/t/9e4813505e83e962?hl=en
* tmio_mmc: keep card-detect interrupts enabled - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d76221b1545c32a5?hl=en
* vhost: make default mapping empty by default - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d473dfaadff5e527?hl=en
* [SOUND] HDA: high cpu usage, noise - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a30980a3c26e24b8?hl=en
* Bug#561229: Bug#561764: some warnings fly off screen and are not saved in
any file - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/10bfcbbbe11580cf?hl=en
* Security: Add prctl(PR_{GET,SET}_NETWORK) interface. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a960a1b4696443c0?hl=en
* Linux 2.6.33-rc1 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e0df79c9c54f5214?hl=en
* gfs2: Use CALLER_ADDR0 macro. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/dccadc096760f05c?hl=en
* kernel: Use CALLER_ADDR0 macro. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f26bd30b420659e6?hl=en
* kernel BUG at kernel/timer.c:951! - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/798f54cd336a4b21?hl=en
* Async suspend-resume patch w/ completions (was: Re: Async suspend-resume
patch w/ rwsems) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/744b2baf61c0ac2a?hl=en
* pata_cmd64x: fix overclocking of UDMA0-2 modes - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/89928bedae9bf8fe?hl=en
* resources: fix call to alignf() in allocate_resource() - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/d16fd11a48e99a0e?hl=en

==============================================================================
TOPIC: sched: restore sanity
http://groups.google.com/group/linux.kernel/t/9e4813505e83e962?hl=en
==============================================================================

== 1 of 10 ==
Date: Sun, Dec 20 2009 9:30 am
From: Joe Perches

On Sun, 2009-12-20 at 16:19 +0100, Peter Zijlstra wrote:
> On Sun, 2009-12-20 at 07:05 -0800, San Mehat wrote:
> > >> Probably, but the rest is just as annoying, pr_* is crap.
> > Oh? Out of curiosity whats wrong with it?
> That's what should be asked of printk().

pr_<level> offers some things printk cannot:

o standardization, eliminates frequent missing KERN_ levels
and missing/typo/misspelled module prefixes
o visually shorter, fewer chars used, less 80 char wrapping
o finer grained ability to eliminate unnecessary messages
for embedded systems
o standardized mechanism to prefix messages with module/function
o eventual code reduction via use of a singleton instead of
duplicated module/function names
o eventual dynamic_debug styled control of prefix by
module/function

There are quite of number of arbitrarily named module wrapper
macros and functions that build on printk.

Standardizing them around a fewer number of prefixes would
ease grepping for logging.

A standardized logging function to filter messages by
bitmask or level could also be useful.

> We try to stick to ANSI-C as much as possible, we've got
> kalloc,kfree,strcmp,strnlen and all the other 'regular' C bits,
> deviating from that serves no purpose but seed confusion.

There is a lot of kernel code that isn't 'regular' C.

Nothing in pr_<level> is not ANSI-C, it just builds on printk.

> But I feel this has no place in the core kernel at all, esp when its
> getting in the way of things without offering a single benefit.

What are the negatives of using pr_<level>?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 10 ==
Date: Sun, Dec 20 2009 9:30 am
From: Joe Perches

On Sun, 2009-12-20 at 15:49 +0100, Ingo Molnar wrote:
> * Peter Zijlstra <peterz@infradead.org> wrote:
> > Revert the braindead pr_* crap.
> > it's dumb and causes stupid "sched: " strings all over the place.
> > -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > -
> > #include <linux/mm.h>
> > #include <linux/module.h>
> > #include <linux/nmi.h>
>
> that's all that we need to remove i suspect, to get rid of the stupid
> prefixes.

True.

== 3 of 10 ==
Date: Sun, Dec 20 2009 9:40 am
From: Peter Zijlstra

On Sun, 2009-12-20 at 09:22 -0800, Joe Perches wrote:
> On Sun, 2009-12-20 at 16:19 +0100, Peter Zijlstra wrote:
> > On Sun, 2009-12-20 at 07:05 -0800, San Mehat wrote:
> > > >> Probably, but the rest is just as annoying, pr_* is crap.
> > > Oh? Out of curiosity whats wrong with it?
> > That's what should be asked of printk().
>
> pr_<level> offers some things printk cannot:
>
> o standardization, eliminates frequent missing KERN_ levels
> and missing/typo/misspelled module prefixes

There's other ways of fixing that, one way is to make it a proper
function argument, like:

printk(char level, char *fmt, ...);

Which is something we have precedent for too in fprintf() and syslog().

> o visually shorter, fewer chars used, less 80 char wrapping

Fuck me senseless, visually less obvious too.

> o finer grained ability to eliminate unnecessary messages
> for embedded systems

How is that not possible with another solution.

> o standardized mechanism to prefix messages with module/function

Who fucking gives a shit, that is the very thing that made me send the
revert.

> o eventual code reduction via use of a singleton instead of
> duplicated module/function names

text reduction?

> o eventual dynamic_debug styled control of prefix by
> module/function

Feh, who cares, printk output simply shouldn't be frequent enough to
need filtering, there's much better solutions for that.

> There are quite of number of arbitrarily named module wrapper
> macros and functions that build on printk.

Then remove them all..

Are you really arguing to fully deprecate printk()? If not this is all
going to be useless since I'll simply keep using printk().

== 4 of 10 ==
Date: Sun, Dec 20 2009 9:40 am
From: Ingo Molnar

* Joe Perches <joe@perches.com> wrote:

> On Sun, 2009-12-20 at 16:19 +0100, Peter Zijlstra wrote:
> > On Sun, 2009-12-20 at 07:05 -0800, San Mehat wrote:
> > > >> Probably, but the rest is just as annoying, pr_* is crap.
> > > Oh? Out of curiosity whats wrong with it?
> > That's what should be asked of printk().
>
> pr_<level> offers some things printk cannot:
>
> o standardization, eliminates frequent missing KERN_ levels
> and missing/typo/misspelled module prefixes
> o visually shorter, fewer chars used, less 80 char wrapping
> o finer grained ability to eliminate unnecessary messages
> for embedded systems
> o standardized mechanism to prefix messages with module/function
> o eventual code reduction via use of a singleton instead of
> duplicated module/function names
> o eventual dynamic_debug styled control of prefix by
> module/function

These are pretty marginal advantages - borderline not worth the resulting
churn. But borderline good patch is still a good patch in my book so i applied
it. Btw., i wish you mixed with real kernel code too instead of going down the
Bunk path. That would reduce such friction substantially IMO - people would
see that you are willing to do (and capable of doing) the harder stuff too.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 5 of 10 ==
Date: Sun, Dec 20 2009 10:00 am
From: Joe Perches

On Sun, 2009-12-20 at 18:36 +0100, Peter Zijlstra wrote:
> On Sun, 2009-12-20 at 09:22 -0800, Joe Perches wrote:
> > On Sun, 2009-12-20 at 16:19 +0100, Peter Zijlstra wrote:
> > > On Sun, 2009-12-20 at 07:05 -0800, San Mehat wrote:
> > > > >> Probably, but the rest is just as annoying, pr_* is crap.
> > > > Oh? Out of curiosity whats wrong with it?
> > > That's what should be asked of printk().
> > pr_<level> offers some things printk cannot:
> > o standardization, eliminates frequent missing KERN_ levels
> > and missing/typo/misspelled module prefixes
> printk(char level, char *fmt, ...);

A change that's not possible without breaking the build of
one rather large body of code.

> Which is something we have precedent for too in fprintf() and syslog().

Huh? Did that break builds?

> > o finer grained ability to eliminate unnecessary messages
> > for embedded systems
> How is that not possible with another solution.

printk is not selective. printk always compiles all
messages, pr_debug eliminates to nothing without DEBUG.
Similar mechanisms are possible for arbitrary pr_<level>.

> > o standardized mechanism to prefix messages with module/function
> Who fucking gives a shit

Apparently the people that prefix.

There are an awful lot of printks with __func__ or
embedded typed function names that I think are senseless.

I think it'd be much more sensible to have some
per module_printk_flags field that controlled whether
or not module/function/line was emitted.

I'm trying to get rid of them slowly and generically.

> > o eventual code reduction via use of a singleton instead of
> > duplicated module/function names
> text reduction?

Yes.

> > o eventual dynamic_debug styled control of prefix by
> > module/function
> Feh, who cares, printk output simply shouldn't be frequent enough to
> need filtering, there's much better solutions for that.

You could name those solutions.

> > There are quite of number of arbitrarily named module wrapper
> > macros and functions that build on printk.
> Then remove them all..
> Are you really arguing to fully deprecate printk()?

I think pr_<level> is a better use.
It's too early to deprecate printk though.

> If not this is all
> going to be useless since I'll simply keep using printk().

I didn't suggest you shouldn't. Use what works for you.

== 6 of 10 ==
Date: Sun, Dec 20 2009 10:00 am
From: Ingo Molnar

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Sun, 2009-12-20 at 09:22 -0800, Joe Perches wrote:
> > On Sun, 2009-12-20 at 16:19 +0100, Peter Zijlstra wrote:
> > > On Sun, 2009-12-20 at 07:05 -0800, San Mehat wrote:
> > > > >> Probably, but the rest is just as annoying, pr_* is crap.
> > > > Oh? Out of curiosity whats wrong with it?
> > > That's what should be asked of printk().
> >
> > pr_<level> offers some things printk cannot:
> >
> > o standardization, eliminates frequent missing KERN_ levels
> > and missing/typo/misspelled module prefixes
>
> There's other ways of fixing that, one way is to make it a proper
> function argument, like:
>
> printk(char level, char *fmt, ...);
>
> Which is something we have precedent for too in fprintf() and syslog().
>
> > o visually shorter, fewer chars used, less 80 char wrapping
>
> Fuck me senseless, visually less obvious too.
>
> > o finer grained ability to eliminate unnecessary messages
> > for embedded systems
>
> How is that not possible with another solution.
>
> > o standardized mechanism to prefix messages with module/function
>
> Who fucking gives a shit, that is the very thing that made me send the
> revert.
>
> > o eventual code reduction via use of a singleton instead of
> > duplicated module/function names
>
> text reduction?
>
> > o eventual dynamic_debug styled control of prefix by
> > module/function
>
> Feh, who cares, printk output simply shouldn't be frequent enough to
> need filtering, there's much better solutions for that.
>
> > There are quite of number of arbitrarily named module wrapper
> > macros and functions that build on printk.
>
> Then remove them all..
>
> Are you really arguing to fully deprecate printk()? If not this is all
> going to be useless since I'll simply keep using printk().

I dont mind that strongly but you (and Mike) objecting to it so forcefully
clearly tips the balance against the pr_*() lines in sched.c so i've queued up
your revert in the scheduler tree.

( I've Cc:-ed Linus and Andrew, in case they care one way or another. )

Thanks,

== 7 of 10 ==
Date: Sun, Dec 20 2009 10:10 am
From: tip-bot for Peter Zijlstra

Commit-ID: 6c9a74afc5d95321e33a727b3c563f3e7d6c4a5c
Gitweb: http://git.kernel.org/tip/6c9a74afc5d95321e33a727b3c563f3e7d6c4a5c
Author: Peter Zijlstra <peterz@infradead.org>
AuthorDate: Sun, 20 Dec 2009 14:23:57 +0100
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Sun, 20 Dec 2009 18:45:57 +0100

sched: Restore printk sanity

Revert the braindead pr_* crap. (Commit 663997d "sched: Use
pr_fmt() and pr_<level>()")

It's dumb and causes stupid "sched: " strings all over the place.

Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Mike Galbraith <efault@gmx.de>
Cc: Joe Perches <joe@perches.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <1261315437.4314.6.camel@laptop>
[ i dont mind the pr_*() patterns that much - but Peter dislikes them with a vengence. ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
--
kernel/sched.c | 89 ++++++++++++++++++++++++++----------------------
kernel/sched_idletask.c | 2 -
2 files changed, 50 insertions(+), 41 deletions(-)
---
kernel/sched.c | 89 ++++++++++++++++++++++++++---------------------
kernel/sched_idletask.c | 2 +-
2 files changed, 50 insertions(+), 41 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index 720df10..7ffde2a 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -26,8 +26,6 @@
* Thomas Gleixner, Mike Kravetz
*/

-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
#include <linux/mm.h>
#include <linux/module.h>
#include <linux/nmi.h>
@@ -5375,8 +5373,8 @@ static noinline void __schedule_bug(struct task_struct *prev)
{
struct pt_regs *regs = get_irq_regs();

- pr_err("BUG: scheduling while atomic: %s/%d/0x%08x\n",
- prev->comm, prev->pid, preempt_count());
+ printk(KERN_ERR "BUG: scheduling while atomic: %s/%d/0x%08x\n",
+ prev->comm, prev->pid, preempt_count());

debug_show_held_locks(prev);
print_modules();
@@ -6940,23 +6938,23 @@ void sched_show_task(struct task_struct *p)
unsigned state;

state = p->state ? __ffs(p->state) + 1 : 0;
- pr_info("%-13.13s %c", p->comm,
+ printk(KERN_INFO "%-13.13s %c", p->comm,
state < sizeof(stat_nam) - 1 ? stat_nam[state] : '?');
#if BITS_PER_LONG == 32
if (state == TASK_RUNNING)
- pr_cont(" running ");
+ printk(KERN_CONT " running ");
else
- pr_cont(" %08lx ", thread_saved_pc(p));
+ printk(KERN_CONT " %08lx ", thread_saved_pc(p));
#else
if (state == TASK_RUNNING)
- pr_cont(" running task ");
+ printk(KERN_CONT " running task ");
else
- pr_cont(" %016lx ", thread_saved_pc(p));
+ printk(KERN_CONT " %016lx ", thread_saved_pc(p));

twitter

Sunday, December 20, 2009

linux.kernel - 23 new messages in 13 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts