lkml.org 
[lkml]   [2012]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/8] Rework KERN_<LEVEL>
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.



\
 
 \ /
  Last update: 2012-06-05 23:41    [W:1.000 / U:0.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site