Refactor kernel strings

Jump to: navigation, search
Reduce kernel size by refactoring strings
Wolfram Sang <>


A side result of the printk compression research task from last year was an analysis of current strings in the Linux kernel. This further lead to promising suggestions how to reduce the Linux kernel size not by compression but by refactoring some string types in the kernel. This proposal is about implementing these suggestions, like:

  • Central emission of strings

If messages are printed by subsystem cores as much as possible, there is no need for every individual driver to do that. By this, we also get rid off a number of inconsistent messages which is a common complaint regarding the Linux kernel. Thus, it helps when dealing with bug reports and numerous platforms, too. An example of this technique from 2014 was removing error strings for devm_clk_get which saved >20K instantly. And there is a huge number of other potential candidates. However, this cannot be blindly done and needs careful preparation to prevent irrelevant messages in optional code paths.

  • Improve prefix handling

The kernel offers printk prefixes which are great for consistent messages. However, they do create unique strings with considerable redundancy in them. For a number of cases, they can be replaced by more memory efficient mechanisms.

  • Add documentation & talk about it

Most important is to create awareness for the string bloat in the kernel. One way to achieve that is to document upstream the findings, present alternatives to bloating, and give rules of thumbs. Another one is to give talks at dedicated conferences about it. So, new developers have a chance to educate themselves and improve their code.

Related work

printk-compression research mentioned above:


I think the main ideas can be discussed and implemented in 120 hours effort. This effort should span over 3-6 months, so there will be enough time for upstream discussion.

Contractor candidates

Given that Wolfram Sang already started digging into the topic, and has some designs sketched and has experience for this task, from working on the printk compression task, I think Wolfram would be a good candidate for this task.. I also think Wolfram has enough upstream experience to deal with such a task.