Posted by
timothy
on from the count-to-ten-very-slowly dept.
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."
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:-)
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
--
Please read my Canon EOS tech blog at http://www.everyothershot.com
I'm trying to think of a reason why ...
by
nels_tomlinson
·
· Score: 3, Insightful
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.
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:)
-- It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
Re:usefulness?
by
walt-sjc
·
· Score: 3, Insightful
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.
Slashdot Mirror
Perl5 does the same thing. read, compile, run..
So what are the uses for this?
-
ping -f 255.255.255.255 # if only
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
Please read my Canon EOS tech blog at http://www.everyothershot.com
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.
See what I've been reading.
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.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
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.
... 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.
:)
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
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
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
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.