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."

usefulness?

[FUF]

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

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.

Re:usefulness?

[nick-less]

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

So you never fucked up your .config and tried to boot a kernel that wont support harddisk without having a backup kernel somewhere? Hell, you seem to be a lot smarter than me...

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:usefulness?

[cbreaker]

I've never made my Linux boxes completly unbootable. I've always put in a link to the old kernel, or something.

Actually, I can't say that - one time lilo locked up the system while installing, and that caused it to not boot. But since that was a bootloader thing, this nifty compile-at-boot thing wouldn't help anyways.

I call shenanigans on this

[Weaselmancer]

I'm posting this from a 2.4Ghz machine myself, and it doesn't compile kernel 2.6 in 15 seconds, let alone boot in that short of a time. It takes at least a couple of minutes.

Hell, "make clean" takes longer than that.

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: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.

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.

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

Yes, it starts booting

[PhilipOfOregon]

but when does it *finish* booting?

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.

Re:usefulness?

[jimicus]

There is a world of difference between re-compiling the kernel and actually getting your nicely recompiled kernel working properly.

However, it's a step in the right direction - I can see Mandrake or SUSE taking this idea and integrating it with some kind of video-driver update system - "Instructions: install this package, reboot."

compile-time kernel

[jproffer]

Hmm very interesting. This could be very useful on embedded systems running linux, using hot-swap or hot-plug technology, and you want to have drivers compiled into the kernel at bootup for faster performance or better stability.

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:usefulness?

[Gherald]

> Grub understands ext file systems and gives you a console that is pretty flexible, so unless you intentionally deleted all backup bootable kernels (shame on you) you should still be able to boot in some manner.

Yeah, like... ummm, KNOPPIX?

Been there done that :)

Re:Too fast...

[SenseiLeNoir]

I think you came with a very good point. Althoguh i "use" Linux a bit, mainly in userland thoguh i have created some workgroup type servers, using wizards provided by Mandrake.

My greatest technical achievement in regards to Linux is trying to compile the kernel after stripping crude from using, and sometiems having the whole thing balls up because I have stripped something that was vital.

I am not your average sysadmin who can figure out every script and knows much about process lists, or Kill Signals.

So although I do view Linux as vastly more stable than Windows, if i get frustrated with a problem i usually follow the following steps.

1) CTRL ALT BACKSPACE to kill and restart X which is great for getting rid of dodgy X-Apps
2) init 1 / init 5 sequence to deal with services or errant processes.
3) reboot.. if the above fails

To be honest I dont mind doing the above, and as i learn more about Linux, i am sure i will learn to avoid such drastic measures. However, until then, anything that speeds up the reboot would be great.

Maybe some sort of "snapshot" feature like the Windows Hibernate, so that you can take a snaphot of Linux post boot/ pre X and instead of going through the entire bolava of booting the kernel, and OS, just loading the snapshot?

Consumer Devices

[pritcharda]

Im wondering if this level of functionality and speed becomes helpful when applied to consumer devices. Or situations where the average user is not able, or capoble, to make changes at this level.

Things like mobile phones. The consumer wont have the abilities to re compile, if say; they connect device like a camera.

The mobile can recognize the device, and retrieve the drivers from the hardware. Then a quick rebuild, and the mobile is configured for the new hardware. (of course a re-boot is still necessary)

Re:usefulness?

[James McTavish]

Agreed that in its present form it is not that useful, but with a couple of features it would become more useful. All they need to do is only have the kernel recompile when the config has changed, and keep an older working kernel around for a failsafe boot. With those two features kernel upgrades become automatic and safe.

That being said, why not just have it recompile while booted. The install script could install the new kernel in lilo/grub and keep the last kernel for a failsafe. The user would simply reboot whenever it was convienent and it would boot straight into the next kernel.

Bottom line, it could become more useful, but there are already better ways to do it.

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 guy is amazing.

[meff]

http://fabrice.bellard.free.fr/ [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 :)

Re:Too fast...

[Zardus]

I used to have a tech support job for which we could spend part of our time administering the help desk's servers if we wanted to. While we were doing that, usually no one would bother us with tech-support questions. At one point, I just launched up

# while [ true ]; do make; make clean; done

and sat back and had a nice relaxing day. Whenever anyone would ask me anything, I'd point to the scrolling compile messages on the screen and tell them that I was busy.

Now that I think back on it, I could have just installed Gentoo on something, which would have been more productive. But, nah...

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.