Date:	Mon, 18 Jun 2007 20:52:30 -0700
From:	Gerrit Huizenga <gh@...ibm.com>
To:	Tim Bird <tim.bird@...sony.com>
cc:	holzheu@...ux.vnet.ibm.com, Jan Kara <jack@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, randy.dunlap@...cle.com,
	gregkh@...e.de, mtk-manpages@....net, schwidefsky@...ibm.com,
	heiko.carstens@...ibm.com,
	"lf_kernel_messages@...ux-foundation.org" 
	<lf_kernel_messages@...ux-foundation.org>
Subject: Re: [RFC/PATCH] Documentation of kernel messages 


On Mon, 18 Jun 2007 17:13:19 PDT, Tim Bird wrote:
> Gerrit Huizenga wrote:
> > Further, yet another kernel config option could allow distros to output
> > the calculated MD5 sum to be printed, much like we do with timestamps
> > today.
> 
> > Comments?
> 
> Would the compiled-in text then also become replaceable?
> Or is the MD5 sum output expected to be in addition to
> the regular English message?
 
 The MD5 sum would be calculated at print time, no proposal in
 here to replace the in-kernel text.  And, I'm not sure that replacing
 it with an MD5 sum would every be significantly shorter, ergo
 I don't think this helps your problem.

 The methods of post-processing to "shrink" the kernel text here
 seem too ugly to ponder.  And I just pondered a few that made my
 head hurt (sort the MD5 sums, re-insert the number of the MD5 sum
 as an integer instead of the original text, and, beyond being gross,
 what do you do with the formatting info about the args?).

> If message replacement at compile-time is supported, this
> could allow for creating "short" versions of the messages,
> which could have a beneficial impact on kernel size.
> 
> Right now, it is possible to completely disable printks
> and re-claim about 100K of memory.  However, in some
> embedded configurations, even if you are space-constrained
> it's desirable to retain some of the printks, for in-field
> debugging.  Thus not very many embedded developers
> disable printks completely, even though the option has
> been supported for a while.  (That, and many aren't caught
> up to the kernel version where it was introduced (2.6.10) :-)

 Which ones matter?  Odds are you could use the KERNEL_LOGLEVEL or
 such to mark those, then compile out the rest.

> But compressed messages (shortened text through abbreviations,
> or just outputting the ID alone, etc.) could save SOME
> of the space, in trade for less readability.  Heck, just
> removing all vowels would probably save 10k, and not
> hurt readability that much.
 
 Ick.  Are you serious?  How about running them through a valley
 girl filter and then converting to high school text messaging?

> Finally, for testing, it's handy to also
> have automatic translation generators.
> At a former company I worked for, they had translators
> that would output:
>  * all messages shortened by 20%
>  * all messages lengthened by 20%
>  * every message converted to pig-latin

 Double yucko.

> These were mostly used for testing if the strings broke
> screen real-estate constraints (which don't apply to
> kernel messages).  But the automatic translators
> would sometimes catch messages with weird attributes.
 
  I don't think people are worried about the correctness of
  the messages and message formats - much of that can actually
  be detected by simple tools.  The goal here was to at least
  allow people that support operating systems and for whom
  English (and English collation sequences) is not a primary
  language do some initial system diagosis.

  I think compiling out the messages of something below some LOGLEVEL
  is a lot more practical.

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

Powered by blists - more mailing lists