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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
