Difference between revisions of "Compressed printk messages"

From eLinux.org
Jump to: navigation, search
(expand description paragraph)
(add Jean-Christophe comment)
Line 50: Line 50:
 
== Comments ==
 
== Comments ==
 
This project was proposed in 2012, but not sponsored that year.
 
This project was proposed in 2012, but not sponsored that year.
 +
 +
Jean-Christophe PLAGNIOL-VILLARD says feature could be useful
 +
for barebox as well.
  
 
[[Category:Project proposals 2012]]
 
[[Category:Project proposals 2012]]
 
[[Category:Project proposals 2013]]
 
[[Category:Project proposals 2013]]

Revision as of 09:54, 3 October 2013

Summary
Compressed printk messages
Proposer
Tim Bird - Sony Mobile Communications

Description

Attempts have been made in the past to compress printk messages to save kernel runtime footprint. There is an option to disable all printks, but many embedded developers do not use it, even when they find the space savings attractive, because they still would like to see kernel debug messages.

This project would consist of researching mechanisms that could be used to automatically (at compile-time) compress the kernel's printk messages, and transparently expand them at runtime.

The goal would be to no have user-visible change in behaviour for the kernel, as well as no required developer-visible changes in the source code. Probably, a new kernel option would be used to control this feature.

The work would involve parsing the kernel source code, extracting the messages (and possibly replacing them in source, during the compilation), compressing them, and replacing the original strings with references to the compressed messages (in a way that the messages can be uncompressed transparently at runtime.)

Miscelaneous issues

There may be an issue with finding all kernel messages, due to the number of macros (probably in the hundreds) that are used to wrap printks. This feature might still be useful, even if not all kernel messages could be converted, as long as significant size savings were made available by using the feature. Significant size savings would be on the order of 50K to 100K.

There might also be some benefit from message consolidation. (I don't know if the compiler already coalesces identical strings, but this system should be able to.)

Related work

Scope

Unknown - 4 to 8 weeks?

Contractor Candidates

None yet.

Comments

This project was proposed in 2012, but not sponsored that year.

Jean-Christophe PLAGNIOL-VILLARD says feature could be useful for barebox as well.