[alsa-devel] [PATCH 0/8] Rework KERN_<LEVEL>
KERN_<LEVEL> currently takes up 3 bytes. Shrink the kernel size by using an ASCII SOH and then the level byte. Remove the need for KERN_CONT. Convert directly embedded uses of <.> to KERN_<LEVEL>
Joe Perches (8): printk: Add generic functions to find KERN_<LEVEL> headers printk: Add kern_levels.h to make KERN_<LEVEL> available for asm use arch: Remove direct definitions of KERN_<LEVEL> uses btrfs: Use printk_get_level and printk_skip_level, add __printf, fix fallout sound: Use printk_get_level and printk_skip_level staging: wlags49_h2: Remove direct declarations of KERN_<LEVEL> prefixes printk: Convert the format for KERN_<LEVEL> to a 2 byte pattern printk: Remove the now unnecessary "C" annotation for KERN_CONT
arch/arm/lib/io-acorn.S | 3 +- arch/arm/vfp/vfphw.S | 7 +++-- arch/frv/kernel/kernel_thread.S | 2 +- drivers/staging/wlags49_h2/hcf.c | 8 +++--- drivers/staging/wlags49_h2/wl_main.c | 4 +- fs/btrfs/ctree.h | 13 ++++++++++ fs/btrfs/disk-io.c | 2 +- fs/btrfs/relocation.c | 2 +- fs/btrfs/super.c | 41 +++++++++++++++++++++++++++++----- include/linux/kern_levels.h | 25 ++++++++++++++++++++ include/linux/printk.h | 41 +++++++++++++++++++-------------- kernel/printk.c | 14 +++++++---- sound/core/misc.c | 13 +++++++--- 13 files changed, 130 insertions(+), 45 deletions(-) create mode 100644 include/linux/kern_levels.h
Make the output logging routine independent of the KERN_<LEVEL> style.
Signed-off-by: Joe Perches joe@perches.com --- sound/core/misc.c | 13 +++++++++---- 1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/sound/core/misc.c b/sound/core/misc.c index 7681679..30e027e 100644 --- a/sound/core/misc.c +++ b/sound/core/misc.c @@ -68,6 +68,7 @@ void __snd_printk(unsigned int level, const char *path, int line, { va_list args; #ifdef CONFIG_SND_VERBOSE_PRINTK + int kern_level; struct va_format vaf; char verbose_fmt[] = KERN_DEFAULT "ALSA %s:%d %pV"; #endif @@ -81,12 +82,16 @@ void __snd_printk(unsigned int level, const char *path, int line, #ifdef CONFIG_SND_VERBOSE_PRINTK vaf.fmt = format; vaf.va = &args; - if (format[0] == '<' && format[2] == '>') { - memcpy(verbose_fmt, format, 3); - vaf.fmt = format + 3; + + kern_level = printk_get_level(format); + if (kern_level) { + const char *end_of_header = printk_skip_level(format); + memcpy(verbose_fmt, format, end_of_header - format); + vaf.fmt = end_of_header; } else if (level) - memcpy(verbose_fmt, KERN_DEBUG, 3); + memcpy(verbose_fmt, KERN_DEBUG, sizeof(KERN_DEBUG) - 1); printk(verbose_fmt, sanity_file_name(path), line, &vaf); + #else vprintk(format, args); #endif
On Tue, 5 Jun 2012 02:46:29 -0700 Joe Perches joe@perches.com wrote:
KERN_<LEVEL> currently takes up 3 bytes. Shrink the kernel size by using an ASCII SOH and then the level byte. Remove the need for KERN_CONT. Convert directly embedded uses of <.> to KERN_<LEVEL>
What an epic patchset. I guess that saving a byte per printk does make the world a better place, and forcibly ensuring that nothing is dependent upon the internal format of the KERN_foo strings is nice.
Unfortunately the <n> thing is part of the kernel ABI:
echo "<4>foo" > /dev/kmsg
devkmsg_writev() does weird and wonderful things with facilities/levels. That function incorrectly returns "success" when copy_from_user() faults, btw. It also babbles on about LOG_USER and LOG_KERN without ever defining these things. I guess they're userspace-only concepts and are hardwired to 0 and 1 in the kernel. Or not.
So what to do about /dev/kmsg? I'd say "nothing": we retain "<n>" as the externally-presented kernel format for a facility level, and the fact that the kernel internally uses a different encoding is hidden from userspace.
And if the user does
echo "\0014foo" > /dev/kmsg
then I guess we should pass it straight through, retaining the \0014. But from my reading of your code, this doesn't work - vprintk_emit() will go ahead and strip and interpret the \0014, evading the stuff which devkmsg_writev() did.
On Tue, 05 Jun 2012 15:11:43 -0700 Joe Perches joe@perches.com wrote:
On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote:
Unfortunately the <n> thing is part of the kernel ABI:
echo "<4>foo" > /dev/kmsg
Which works the same way it did before.
I didn't say it didn't.
What I did say is that echo "\0014">/dev/kmsg will subvert the intent of the new logging code. Or might. But you just ignored all that, forcing me to repeat myself, irritatedly.
On Tue, 2012-06-05 at 15:17 -0700, Andrew Morton wrote:
On Tue, 05 Jun 2012 15:11:43 -0700 Joe Perches joe@perches.com wrote:
On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote:
Unfortunately the <n> thing is part of the kernel ABI:
echo "<4>foo" > /dev/kmsg
Which works the same way it did before.
I didn't say it didn't.
What I did say is that echo "\0014">/dev/kmsg will subvert the intent of the new logging code. Or might. But you just ignored all that, forcing me to repeat myself, irritatedly.
It works the same way before and after the patch.
Any write to /dev/kmsg without a KERN_<LEVEL> emits at (1 << 3) + KERN_DEFAULT.
Writes with <n> values >= 8 are emitted at that level.
On Tue, 05 Jun 2012 15:49:32 -0700 Joe Perches joe@perches.com wrote:
On Tue, 2012-06-05 at 15:17 -0700, Andrew Morton wrote:
On Tue, 05 Jun 2012 15:11:43 -0700 Joe Perches joe@perches.com wrote:
On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote:
Unfortunately the <n> thing is part of the kernel ABI:
echo "<4>foo" > /dev/kmsg
Which works the same way it did before.
I didn't say it didn't.
What I did say is that echo "\0014">/dev/kmsg will subvert the intent of the new logging code. Or might. But you just ignored all that, forcing me to repeat myself, irritatedly.
It works the same way before and after the patch.
Any write to /dev/kmsg without a KERN_<LEVEL> emits at (1 << 3) + KERN_DEFAULT.
Writes with <n> values >= 8 are emitted at that level.
What about writes starting with \001n? AFACIT, that will be stripped away and the printk level will be altered. This is new behavior.
On Tue, 2012-06-05 at 16:29 -0700, Andrew Morton wrote:
What about writes starting with \001n? AFACIT, that will be stripped away and the printk level will be altered. This is new behavior.
Nope.
# echo "\001Hello Andrew" > /dev/kmsg /dev/kmsg has 12,774,2462339252;\001Hello Andrew
12 is 8 + KERN_DEFAULT
# echo "<1>Hello Andrew" > /dev/kmsg /dev/kmsg has: 9,775,2516023444;Hello Andrew
participants (2)
-
Andrew Morton -
Joe Perches