lkml.org 
[lkml]   [2008]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch 1/3] kmsg: Kernel message catalog macros.
From
Date
On Thu, 2008-08-14 at 08:40 -0700, Tim Hockin wrote:
> On Aug 13, 2008 9:15 PM, "Rusty Russell" <rusty@rustcorp.com.au> wrote:
>
> > On Wednesday 13 August 2008 17:04:11 Tim Hockin wrote:
> >> But there are a number of places that have ...Well, if they're to be the
> >> same messages under the manual-numbering scheme,
> >
> > someone has to verify that they are really the same anyway. Not much more
> > work to simply fix them in that case, is it?
> >
> > If it improves normal kernel messages, then everyone wins.
>
> Oh, I agree with that. I personally don't care much for the msg ID part of
> this patch (I mean I don't care either way). It might be nice to have man
> pages, but I just see it becoming out of sync, duplicate numbers, etc.

No, the kmsg-doc script will prevent that the kmsg message will become
of of sync and it checks for duplicate numbers. The idea here is that
the kmsg man pages are generated with the kernel compile (just try it
with "make D=2").

> What I want to see is the elevation of these call-sites from "it's just a
> printk()" to "it's a report-worthy event and part of our user<->kernel API". I
> want people to add them when it's appropriate and then not change the strings
> later. I don't care if, in the end, they are structured strings. I do care if
> I have to run dozens of regexes against thousands of log-lines on thousands of
> systems.
>
> :)

Yes, and this has already happened with the s390 device driver messages.
With the conversion to kmsg our developers removed a lot of crud from
the code, this alone makes it worthwhile.

--
blue skies,
Martin.

"Reality continues to ruin my life." - Calvin.




\
 
 \ /
  Last update: 2008-08-14 19:15    [W:0.098 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site