lkml.org 
[lkml]   [2008]   [Aug]   [16]   [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 Fri, 2008-08-15 at 09:22 +1000, Rusty Russell wrote:
> On Friday 15 August 2008 03:07:03 Martin Schwidefsky wrote:
> > On Wed, 2008-08-13 at 14:33 +1000, Rusty Russell wrote:
> > > On Thursday 31 July 2008 02:56:57 Martin Schwidefsky wrote:
> > > > From: Michael Holzheu <holzheu@de.ibm.com>
> > > > From: Martin Schwidefsky <schwidefsky@de.ibm.com>
> > > >
> > > > Introduce a new family of printk macros which prefixes each kmsg
> > > > message with a component name and allows to tag the printk with a
> > > > message id.
> > >
> > > Can you hash the format string to generate the id? 6 hex digits should
> > > be enough, and your tool can check for clashes. As it's bad form to have
> > > identical strings for different semantics anyway, this seems to make
> > > sense.
> >
> > First, how do you do that with the C preprocessor? Second the kmsg-doc
> > script will check that the message format strings match if a kmsg with a
> > specific id is used in multiple locations.
>
> Well, why would you do it with the preprocessor? It's simplest to spit it out
> at runtime.

Ok, so a specialized version of printk will do the work to calculate
the hash. Only, what will we do if there ever is a conflict? The message
tag has to be unique. The shorter the hash is, the more likely a
collision gets. Don't know if 6 hash digits is enough to just ignore the
problem.

> The (offline) catalogger will need to generate them, of course.
> Rusty.

Sounds doable to me.

--
blue skies,
Martin.

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




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