TCCBOOT Compiles And Boots Linux In 15 Seconds

An anonymous reader writes "TCCBOOT is the first boot loader able to compile and boot a Linux kernel directly from its source code. It can compile and start booting a typical Linux kernel in less than 15 seconds on a 2.4 GHz Pentium 4. TCCBOOT uses the latest version of the TinyCC C compiler."

Comments

Too fast...

[smudge8]

To be honest, I LIKE the delay when I have to reboot. It gives me time to have a pee, stretch my legs, have a drink...

Eventually we're going to spend 24 hours a day staring at the screens because there'll be no excuse at all for leaving the screen.

Re:Too fast...

[Dasein]

there'll be no excuse at all for leaving the screen

Um. Social life, family, sex, ....

Yes, I do realize that I'm posting to slashdot.

Re:Too fast...

[wrook]

That might be OK for Windows. For Linux, you might not want to wait for a reboot to take a pee. Just a word of warning...

Re:Too fast...

[stratjakt]

I reboot my machines all the time, because it's easier than ssh'ing in, and figuring out what the problem is.

One is mainly an LDAP server/PDC, and for some reason OpenLDAP just dies once in awhile. Has something to do with BDB settings, I'm supposed to know some magical cache size setting or something to make it stable. I have no time for that. It boots from a RO image, which I rarely need to update.

Same for the firewall/gateway. It's just much easier to tell people "if the internet or vpn isnt working, reset this box and wait a minute".

Linux can have really really long uptimes, but only if you have an admin who can babysit it and solve problems without rebooting.

I'm not an admin, and I don't have time to figure out why "dhcpcd" or "dnsmasq" decided they dont need to spawn anymore. While such problems could probably be easily fixed by deleting some lockfile or clearing some log, rebooting is just easier.

Linux needs to be able to boot fast to move forward, especially in the world of "embedded" or single-function PCs.

Re:Too fast...

[D-Cypell]

I LIKE the delay when I have to reboot. It gives me time to have a pee, stretch my legs, have a drink...

Then I suggest you stay away from windows, you will end up as a dehydrated, 12 foot alcholic!

Re:Too fast...

[rattler14]

well said!

plus, my boss really thinks i'm working hard when he sees 4 terminals open with stuff flying past them. hence, i always compile from source

script?

[sporty]

So they effectively make the kernel a script instead of a compiled unit, where it needs to be loaded, compiled into memory, and then used.

Perl5 does the same thing. read, compile, run..

So what are the uses for this?

Re:script?

[vidarh]

Comparing it to Perl is a bit unfair considering we don't exactly have a full fledged Unix like kernel written in Perl to boot...

I prefer to see this as a great proof of concept that kernel compilation can be made fast enough to do "on the fly". Considering that driver installation for Linux still often requires a kernel recompile, if this system can be made solid enough it could make things like that a lot easier for end users, though I think I'd prefer to have it done at package installation time rather than boot time :-)

usefulness?

[FUF]

Why would anyone *possibly* want their bootloader be able to compile the kernel?

Re:usefulness?

[Walkiry]

Two words: ATI drivers. These fuckers have to be compiled in the kernel, and I don't doubt there may be some other dumbasses who make similar drivers for other stuff. If the kernel just compiles like that (as in, is designed to just compile on boot), it'd make messing with the drivers less painful.

Re:usefulness?

[Jahf]

No it wouldn't. You'd still have to reboot to see the change ... at least if you compile -before- the reboot you know that the compile worked.

Plus using this mechanism as-is without alternative boots would mean compiling your kernel every time you boot. A waste of time and resources.

Note that it didn't say it booted in 15 seconds ... only that it -started- to boot in 15 seconds. Even removing all modules I find it impossible to believe that a P4 could compile the entire kernel with -any- compiler faster than it takes to load a precompiled kernel. No matter what you still have a "+ compile time" situation even if it is much faster than the stock gcc.

This has some "because you can" value, but otherwise I just don't see it as being useful to the user, or even to the vast majority of kernel developers.

Making C feel like Perl is not a good thing for me :)

Re:usefulness?

[walt-sjc]

Nice troll. That's like saying: "if you CAN drive your car into a tree, then that's a very serious design flaw." There is no way that you can design a general purpose OS that is immune to "operator head-gap errors." Believe me: I can easily screw up Windowsi, MacOS, any flavor of Unix, etc. to the point where they won't boot by going in and playing with the registry, system settings, driver resources, etc.

The only way you can prevent this is to prevent the tinkering in the first place, which is what all the appliance type systems do. Even then, you can always pop the hood and start reflashing the eproms, etc. rendering the device non-functional.

Linux runs on Many different architecturs and supports THOUSANDS of different devices. Because you have the ability to cross-compile and include / exclude support for just about anything, it's trivial to create a non-functional kernel. This is NOT a design flaw.

Back to the topic at hand... It would be very cool to include hardware / device detection and auto-compile all the different modules / support needed to run on any particular platform, even optimizing for the local processor. Furthermore, you do this via netboot / PXE as well as a boot CD. I dont know what capabilities tinycc has for optimization - probably none, but that may be something that could be added.

What we really want to know is

[Anonymous Coward]

How long does it take to boot Gentoo?

Hmm

[Anonymous Coward]

If only they could apply this to compiling the rest of Gentoo . . .

Yes, but...

[Anonymous Coward]

does it run Linux?

Do you know what this means?!

[AKAImBatman]

This could allow for platform independent Linux programs! i.e. If programs could be compiled on the fly from source bundles as an acceptable speed, then there would be no need to distribute binaries any longer. One source bundle, and you'll rule them all!

Failing that, one could always fall back on my previous plan. My thought was that if GCC compiled to P-Code instead of the final binary, the target GCC could complete the P-Code conversion at install time.

But why?

[jolyonr]

It doesn't actually explain on the site why anyone would want to do this.

And I'm still not sure! What's wrong with compiling it every time the code changes and booting up quicker than 15 seconds?

Jolyon

Re:But why?

[mbrezu79]

Well, I'm no kernel hacker, but I guess this could help speed up the debug cycle for the kernel in some instances.

It could also be a trap (it runs well compiled with tcc but fails misteriously when compiled and optimized with gcc).

TCC is a very fast C compiler and it is very nice for development (I used it as a backend to the SmartEiffel Eiffel compiler, it greatly speeds up compiling - waiting for GCC every time was a nuissance) and I guess Fabrice Bellard likes to experiment.

I guess nobody (including Bellard) believes TCC is any good for delivered apps (it doesn't optimize etc.) but it can provide a huge boost to edit-compile-debug cycles.

So yes, TCC is very cool, but not useful for the general public.

Re:But why?

[CedgeS]

fibo.c from GCLS:

cedric@cedric:~$ time tcc fibo.c -o fibo.tcc

real 0m0.060s
user 0m0.020s
sys 0m0.010s
cedric@cedric:~$ time gcc fibo.c -O3 -o fibo.gcc

real 0m0.441s
user 0m0.150s
sys 0m0.030s
cedric@cedric:~$ time ./fibo.gcc
1

real 0m0.074s
user 0m0.000s
sys 0m0.000s
cedric@cedric:~$ time ./fibo.tcc
1

real 0m0.072s
user 0m0.000s
sys 0m0.000s
cedric@cedric:~$ time ./fibo.gcc
1

real 0m0.071s
user 0m0.000s
sys 0m0.000s
cedric@cedric:~$ time ./fibo.tcc
1

real 0m0.074s
user 0m0.000s
sys 0m0.000s
cedric@cedric:~$ time ./fibo.gcc
1

real 0m0.071s
user 0m0.000s
sys 0m0.010s
cedric@cedric:~$ time ./fibo.tcc
1

real 0m0.070s
user 0m0.000s
sys 0m0.000s

I can't believe this is what GCLS uses as a benchmark. The running time is so short it's probably all start-up and shutdown. Anyway, the numbers are pretty fair for a compiler compiling code that was tweaked to get the other compiler to be as fast as possible.

I'm trying to think of a reason why ...

[nels_tomlinson]

I know that the answer to ``why?'' is ``why not?''. but I'm trying to think of some practical use for this.

Maybe you could use some Knoppix-style hardware detection to probe the hardware at boot-time, then custom-compile a kernel to match? I just can't really see that that would be an improvement over just compiling in everything and the kitchen sink as a module.

Oh, well, even if it's useless, it's neat.

Not a complete compile

[cbreaker]

The README says it needs some of the binaries and headers on the linux kernel, so you have to pre-compile these first.

I guess this could have some limited use somewhere, perhaps, but I can't really see how if you need some precompiled stuff.

Great for Gentoo

[Solder Fumes]

Now they can compile their kernel with "-mday=Wednesday" for even better optimization.

Re:Great for Gentoo

[Solder Fumes]

I'm so sorry for being distro-ist. I apologize to all Gentoo-Americans for my extreme insensitivity.

How?

[wowbagger]

How can this thing:

Load the needed environment for the compiler.
Load the source
Build the source
Boot the source

in 15 seconds, when it takes much longer than that for my already booted system to build a kernel? A P4 isn't THAT much faster than an AMD3200! (And I have done the old "drop to RL1 and build" trick, so it is not an issue of other tasks running).

I want to know a) What kernel options are enabled b) From when are they starting the clock (are they counting the time to load the bootloader and initrd?) and c) is this TRULY a fully functional kernel, or "just enough to get a prompt"?

Re:How?

[vidarh]

TCC is an incredibly tiny compiler with practically no dependencies on the environment. It's based on a cleaned up entry to the obfuscated C contest. So you can safely assume it's using every dirty trick in the book and then some. It still sounds incredible though.

Re:How?

[maxwell demon]

Non-optimizing compilers can be very fast. Basically you just have to parse it and output pre-defined asm for each bit. According to this page, Turbo C 2.01 (a 1989 product) compiles over 16,000 lines per minute. Given that this number is also on the advertisement shown in that picture, which is actually from that time, it's 16,000 lines on the hardware of that time (i.e. 386). Now IIRC the 386 had at most 33MHz, so from the clock speed difference alone, on an 2.4GHz computer it should compile about 1.16 million lines per second; assuming a factor 4 in efficiency (i.e. modern processors can do 4 times as much per clock cycle as an 386), it should be possible to compile the same amount in 15 seconds. Now according to this page the Linux kernel has 1,526,722 lines of code, so if either my efficiency factor of 4 was too low, or TCC can compile about 1.5 times as fast as Turbo C 2.0 could (or maybe a combination of both), it's clearly not that far-fetched that a linux kernel could be compiled in 15 seconds.

Re:How?

[LiENUS]

Actually the TinyCC site lists a speedchart at http://fabrice.bellard.free.fr/tcc/#speed measurements are done on a 500 MHz K6. That should give you a better idea than just estimating based on Turbo C 2.0

Wow! Ultimate Gentoo!

[Eunuchswear]

Recompile your programs EVERY TIME YOU RUN THEM.

Ricers Rule!

Wow

[physicsphairy]

My windows box and I would still be trying to negotiate whether it wanted to boot in "Normal Mode" "Safe Mode" "Last Known Good Configuration" or "Sorry, chap, just not gonna happen."

Main reason for this?

[kbahey]

I think the main thing here is the TCC compiler, which is 100K or so, and very fast.

This TCCBOOT is something to showcase the speed of the TCC compiler.

Re:Main reason for this?

[kbahey]

You are generally right.

But think about it for a bit: this fast C compiler turns the tables, and redefines what we know (paradigm shift anyone?). No longer will C be seen as a compiled language. One can think of it as a scripting language. A construct like this works with tcc:

#!/usr/local/bin/tcc -run
main()
{
DoSomethingHere();
}

Something that was unthinkable under GCC.

As someone else posted, this can mean the proliferation of self contained bundles that are platform independant.

The potential is enormous. Not the boot part, but the compiler and what it can be twisted into doing.

This should go over BIG..

[murderlegendre]

..with the Gentoo crowd.

The once impossible dream of actually compiling the Linux kernel on every boot is now a shining reality.

Wha?

[stratjakt]

It takes a couple minutes to compile my kernel on a 3.06 P4, and of course, forever and a day to boot.

I guess 15 seconds is to compile without any device support other than the boot drive.

That said, linux boot time as it is sucks, especially if you want to use it on something like a router/firewall box like I do. The only button I ever press on that machine is reset. VPN not working? Reset.

That's how it should work IMO, but every time I do it the 'net is out for 10 mintues until it's back up.

Resetting the whole box should be faster than ssh'ing in and typing a "/etc/init.d/shorewall restart" and "/etc/init.d/openvpn restart".

Wow. That really is fast.

[TheRaven64]

Out of sheer boredom, I just downloaded the demo ISO and ran it inside VirtualPC on a 1.5GHz G4. The emulated system is probably roughly equal to a P2 300. The total time from turning the emulated machine on to a shell was around a minute.

Blatant Karma Whoring: In case of a slashdotting..

[jimicus]

Introduction
TCCBOOT is a boot loader able to compile and boot a Linux kernel directly from its source code.

TCCBOOT is only 138 KB big (uncompressed code) and it can compile and run a typical Linux kernel in less than 15 seconds on a 2.4 GHz Pentium 4.

TCCBOOT is based on the TinyCC compiler, assembler and linker. TinyCC is an experiment to produce a very small and simple C compiler compatible with the GNU C compiler and binary utilities.
Screenshots
Download
ISO image demonstation: tccboot.iso (5.9 MB).

Create a CD from it and boot it to see TCCBOOT in action (PC with at least 64 MB of RAM required). You can also try it with the QEMU PC emulator.

TCCBOOT source code: tccboot-0.1.tar.gz, and README file.

Re:Wow. That really is fast.

[TheRaven64]

I just ran the same thing again (exactly the same configuration), with a stopwatch. 46 seconds. 15 seconds on a P4 sounds like they were being a bit pessimistic. Note that this doesn't include launching any daemons, or a

sh-2.05b# ps -x
PID TTY STAT TIME COMMAND
1 ? S 0:01 /bin/sh /sbin/init auto
2 ? SW 0:00 [keventd]
3 ? SW 0:00 [bdflush]
4 ? SW 0:00 [kupdated]
5 ? SWN 0:00 [ksoftirqd_CPU0]
6 ? SW 0:00 [kswapd]
15 ? S 0:00 /bin/sh
17 ? R 0:00 ps -x

Re:Just-in-time compilation

[maxwell demon]

Well, maybe a BIOS-integrated Emacs automatically launches and allows you to edit the code ...

Re:I call shenanigans on this

[Godeke]

Looking at benchmarks for TCC, combined with the fact this needs kernel patches to work, I don't see this as shenanigans.

15,000 - 16,000 lines per second for GCC vs 134,000 lines per second is a pretty huge speed improvement.

On the other hand, if "make clean" takes longer than 15 seconds on your machine, I have to wonder what you are doing. I'm typing this on a lowly 550 Mhz Pentium with 512 MB of RAM (running a full KDE install) and I can assure you I would be unhappy if running "clean" took that long.

Imagine a

[multiplexo]

Beowulf cluster of these. Together they'd boot so fast that you'd go back in time!

Re:TCC compiler

[TheRaven64]

TCC has a few significant drawbacks.

1. It is not portable (well, technically it is portable, but currently only has an i386 back end).
2. It only supports C (not a drawback if you are just compiling C, but a lot of projects use C++/Objective-C/Whatever).
3. It produces fairly sub-optimal code. The register allocation done by TCC is not very clever, and it performs no serious optimisation steps.

On the other hand, TCC has two huge advantages:

1. It is not GCC. Compiling your code using two or more compilers and ideally for 2 or more CPU architectures is a good way of finding some more obscure bugs.
2. It is very fast. The less time you spend compiling, the more time you can spend testing / debugging.

This guy is amazing.

[meff]

http://fabrice.bellard.free.fr/

Just look at this guy's work.. It's amazing what this he can do.
If you haven't tried it yet, definately check out QEMU, it's great, and totally free.
He also wrote FFMPEG which most definately your linux media player uses..

I am always wondering what he'll put out next :)