Re: What happened to Linux-Tiny ?

Rob Landley

On Tuesday 12 January 2010 08:13:03 Michael Opdenacker wrote:
Hi Holger,

On 01/12/2010 10:19 AM, Holger Schurig wrote:
On I see that there's no public
release of Linux-Tiny-Patches since Kernel 2.6.23. Is this
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,
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

Join to automatically receive all group messages.