[Celinux-dev] What happened to Linux-Tiny ?

Rob Landley rob at landley.net
Thu Jan 14 09:37:58 UTC 2010

On Tuesday 12 January 2010 08:13:03 Michael Opdenacker wrote:
> Hi Holger,
> On 01/12/2010 10:19 AM, Holger Schurig wrote:
> > On http://elinux.org/Linux_Tiny I see that there's no public
> > release of Linux-Tiny-Patches since Kernel 2.6.23. Is this
> > right?
> That's right. We stopped releasing patches after realizing that we were
> spending more time updating old patches than getting them merged.
> Thanks to this, we managed to merge some of these patches (see
> http://free-electrons.com/community/contributions/kernel-contributions/),
> but it's true that some patches / ideas haven't been merged yet.

Back when Matt Mackall gave up on the first linux-tiny tree, I realized that 
the fundamental problem with linux-tiny is it's going about it all wrong.

Think about embedded development in userspace.  People who put together their 
first headless box tend to start by grabbing a desktop distro and uninstalling 
stuff they don't need.  But after a while you have to approach the problem from 
the other end, starting with an empty root filesystem and adding just what you 
need.  Whether you do so with cp and ldd, or whether you build stuff from 
source, is a side issue.  The point is instead of starting with buckets of 
stuff and chopping it down, you start from zero and build _up_.

The linux kernel's "allnoconfig" produces a kernel that's over a megabyte.  The 
linux-tiny patches are finding ways to disable more of that stuff, but it's 
still the "start with a distro and remove stuff" approach.  That's a Red 
Queen's Race, you're running at full speed to avoid _losing_ ground.

What's needed is a "hello world" Linux kernel, that makes the smallest 
bootable binary you can actually see do something.  Start with Linux, grab 
whatever setup.S code you need to get the processor ready to run C code, plus 
the early_printk stuff to print "hello world" out to a simple console device, 
and then halt the CPU.  Make that work on each target.

Then once you've got your zero state, then add the compression wrapper.  Then 
work your way through init/main and start adding stuff a bit at a time, with 
stub versions of everything (possibly copied from linux 0.95 or thereabouts).  
The world's crappiest in-kernel memory allocator.  A mindless round-robin 
scheduler.  Sad interrupt handling that just _does_ it without even bottom 
halves.  A single mount point vfs.  The posix system calls, and so on.  Figure 
out what they ARE.  Look at linux 0.0.1 to see the minimum you can get away 
with.  Disentangle each of these chunks from each other and try to figure out 
if there's any possible use you could put the system to without this one.

Note that kernels are potentially actually useful even in the absence of 
userspace.  Back in the 2.2 days there was as trick where you'd set up your 
ipchains so everything was routing and masquerading how you wanted, and then 
intentionally have init exit (panicing the kernel).  The machine would still 
handle interrupts and thus still route packets, but there was no userspace.  
(Try running your rootkit on _that_ box.)  I don't think it still works on 
modern systems, but you see my point.

Imagine a kernel that does nothing but parse a device tree, probe a little bit 
of described hardware and early_printk some information about it, and then 
halt.  That's a tool on the order of memtest86 that's conceivably useful as an 
early smoketest, and the fact it _can't_ currently be built from the Linux 
source is _sad_.

The thing is, making such a "hello world" kernel is a HUGE amount of work, and 
then breaking out other pieces of code from Linux so they're independent of 
each other and can be added one at a time would be an enormous undertaking.  
Right now it's all one big huge tangled mess.  But working from the top down 
does not scale, you have to take the bottom up approach at some point, or else 
accept that the kernel will continue to bloat and that linux-tiny and friends 
are at best a holding action.

(I blathered about this a bit in that OLS compiler BOF Michael recorded in 
2008.  Haven't found time to mess with it much since.  Not really my area, I'm 

Latency is more important than throughput. It's that simple. - Linus Torvalds

More information about the Celinux-dev mailing list