Kernel space: A tiny Linux for the embedded world

Linux has the text of 60,000 error and debug messages built-in. With bytes at a premium on phones and other devices, developers are looking for a way to make the kernel smaller and less chatty.

By Jake Edge, LinuxWorld.com, 10/02/07

 Start a discussion    Print article

 Comments (1)    Print article

An announcement of the revival of linux-tiny, a set of patches aimed at reducing the footprint of the kernel, mainly for the embedded world, has led to a number of linux-kernel threads. The conversations range from the proper place for linux-tiny to reside to the removal of the enormous number of printk() strings in the kernel. They provide an interesting glimpse into the kernel development process.

The linux-tiny project was started by Matt Mackall in December 2003 with the aim to "collect patches that reduce kernel disk and memory footprint as well as tools for working on small systems." LWN covered the announcement at the time and tried out the patches more than a year ago. Many of the linux-tiny features have found their way into the mainline, but quite a few still remain outside.

The Consumer Electronics Linux Forum (CELF) is behind the effort to revive the project, with Tim Bird, architecture group chair, announcing the plan, including a new maintainer, Michael Opdenacker. The first step has been mostly completed, bringing the patches forward from the 2.6.14 kernel to 2.6.22. A status page has been established to track the progress of updating the patches, but it is clear that moving them into the mainline, rather than maintaining them as patches, is a big motivation behind the revival.

Andrew Morton immediately volunteered to manage the linux-tiny patches in an answer to the revival message:

Seriously, putting this stuff into some private patch collection should be a complete last resort - you should only do this with patches which you (and the rest of us) agree have no hope of ever getting into mainline.

Reactions were quite favorable, with the maintainer, Opdenacker responding:

Andrew, you're completely right... The patches should all aim at being included into mainline or die.

I'm finishing a sequence of crazy weeks and I will have time to send you patches one by one next week, starting with the easiest ones.

The full patchset will live in a separate repository as the individual patches are being worked on for inclusion, but it is clear that no one wants to continuously maintain and out-of-tree patchset for a long time. The cost of ensuring that the patches do not bitrot is large and their inclusion in the mainline will get them in the hands of more developers.

Featured Whitepapers

LinuxCast Listen to the latest Linux news.

About Us | Contact Us | Advertising Info | Terms of Service/Privacy

Copyright, 2006-2007 Network World, Inc. All rights reserved.