| | |
Mr. Torvalds, Shrink That Kernel
Linus Torvalds, creator of the Linux kernel, said at the LinuxCon in Portland yesterday that, "We are not the streamlined, small, hyper-efficient kernel I envisioned 15 years ago," he said. "Our kernel is huge and bloated. Whenever we add a new feature, it only gets worse." It's time to put Linux on a diet. What we need is a very small kernel that loads support via external files. Though Linux is a modular kernel, it seems that everything gets compiled in to the central code slug but I have a solution.
Instead of making the kernel impossibly huge and compiling in support for device X and peripheral Y, let's move support for all devices to XML files and just have the kernel read the ones we want. No recompiling. No derivative works in the kernel. And no debate needed between Tannenbaum and Torvalds over microkernels vs monolithic kernels.
Move support for everything to a directory or special filesystem, like /proc, where all of the necessary XML files reside. The kernel picks them up and uses them with no changes to the kernel and no kernel bloat required. Now, I have to tell you that IANAP (I am not a Programmer) by any stretch of the imagination but it seems to me that this would have been something that others would have thought up before now.
I'm a long-time user of Linux, an early adopter and the founder of the local Linux User's Group back in 1996. The first meeting of that LUG was spent on teaching others how to recompile their kernel so that they could add or remove support for devices and peripherals.
This was, and is, a totally unnecessary activity. Recompiling a kernel should be reserved for very rare circumstances.
Admittedly, I haven't recompiled a kernel in at least four years. I just deal with what I'm given at this point. I no longer have the energy or the time it takes to recompile and recompile and recompile until I get it just so.
So, to Linus and the other kernel maintainers: What do you think? Can we make this work? Pull out all of the kernel bloat and make it cafeteria style.
I wonder if Andrew Tannenbaum would like this idea?
What do you think of my plan to truly modularize and right size the kernel? Write back and let me know.
Instead of making the kernel impossibly huge and compiling in support for device X and peripheral Y, let's move support for all devices to XML files and just have the kernel read the ones we want. No recompiling. No derivative works in the kernel. And no debate needed between Tannenbaum and Torvalds over microkernels vs monolithic kernels.
Move support for everything to a directory or special filesystem, like /proc, where all of the necessary XML files reside. The kernel picks them up and uses them with no changes to the kernel and no kernel bloat required. Now, I have to tell you that IANAP (I am not a Programmer) by any stretch of the imagination but it seems to me that this would have been something that others would have thought up before now.
I'm a long-time user of Linux, an early adopter and the founder of the local Linux User's Group back in 1996. The first meeting of that LUG was spent on teaching others how to recompile their kernel so that they could add or remove support for devices and peripherals.
This was, and is, a totally unnecessary activity. Recompiling a kernel should be reserved for very rare circumstances.
Admittedly, I haven't recompiled a kernel in at least four years. I just deal with what I'm given at this point. I no longer have the energy or the time it takes to recompile and recompile and recompile until I get it just so.
So, to Linus and the other kernel maintainers: What do you think? Can we make this work? Pull out all of the kernel bloat and make it cafeteria style.
I wonder if Andrew Tannenbaum would like this idea?
What do you think of my plan to truly modularize and right size the kernel? Write back and let me know.
Last edited by khess; Sep 22nd, 2009 at 11:15 am.
0
•
•
•
•
I've always said, Tanenbaum must be so pissed.
Anyway, I think having code you don't have to compile at every turn very convenient but it could also be slow. Imagine if the kernel modules were written in Python. Get the jist?
Anyway, I think having code you don't have to compile at every turn very convenient but it could also be slow. Imagine if the kernel modules were written in Python. Get the jist?
0
•
•
•
•
Streamlining the kernel is a really good idea. It will/may give more developers an easier learning curve than as it is currently
0
•
•
•
•
It is *NOT* that difficult to streamline any kernel - anyone who can read a howto can figure it out and there are plenty of them out there for each distro - Google is your friend.
Yes it *does* require some trial and error, maybe Google searching device numbers, and a bit of hardware knowledge of what is in your system. It is much easier than before to identify what is in your system - try lshw or lspci, then before you compile your kernel, *REMOVE THE STUFF YOU DON"T NEED*.
Gentoo has suggested it this way for years and every time I set up a Gentoo system I am blown away by the speed of the system. I currently have a dual-boot Ubuntu 8.04LTS and Gentoo ~amd64 on this laptop and have had no issues.
Of course the Gentoo system is UNSTABLE since I am running that branch, and I can (most of the time) figure out what the problem is using Google, the forums, and the bugzilla. Other times I have to roll-back individual troublesome packages and then all is well.
No I am not a developer, maintainer, or even an IT admin - I just figured this out on my own.
Anyone can...
Yes it *does* require some trial and error, maybe Google searching device numbers, and a bit of hardware knowledge of what is in your system. It is much easier than before to identify what is in your system - try lshw or lspci, then before you compile your kernel, *REMOVE THE STUFF YOU DON"T NEED*.
Gentoo has suggested it this way for years and every time I set up a Gentoo system I am blown away by the speed of the system. I currently have a dual-boot Ubuntu 8.04LTS and Gentoo ~amd64 on this laptop and have had no issues.
Of course the Gentoo system is UNSTABLE since I am running that branch, and I can (most of the time) figure out what the problem is using Google, the forums, and the bugzilla. Other times I have to roll-back individual troublesome packages and then all is well.
No I am not a developer, maintainer, or even an IT admin - I just figured this out on my own.
Anyone can...
0
•
•
•
•
•
•
•
•
Move support for everything to a directory or special filesystem, like /proc, where all of the necessary XML files reside. The kernel picks them up and uses them with no changes to the kernel and no kernel bloat required. Now, I have to tell you that IANAP (I am not a Programmer) by any stretch of the imagination but it seems to me that this would have been something that others would have thought up before now.
Similar Threads
- hidden files in external hard drive (Storage)
- News Story: Where Are All The Linux Netbooks? (Linux Servers and Apache)
- News Story: Linux powered OLPC unable to hit $100 target price (Linux Servers and Apache)
- News Story: Does Solaris need to be better Linux than Linux? (Linux Servers and Apache)
- ipod on linux? help... (*nix Hardware Configuration)
- News Story: Dellbuntu remains a Linux fantasy (Linux Servers and Apache)
- What type of linux to use?? (Getting Started and Choosing a Distro)
- Having roblems using PHP to send info as text file (PHP)
- Corrupted HDD? (Storage)
| Thread Tools | Search this Thread |
age amd api apple avatar bbc bluegene browsers centos chips cisco citrix cloudcomputing code database debian dell desktop desktops development distributions dos economy energy enterprise fedora france gadgets gnome google gos gpl hardware hp hyper-v ibm ibm.news intelibm java kde kernel laptop laptops linustorvalds linux linuxfoundation mac macosx medicine memory microsoft mobile netbook netbooks news novell open openoffice opensolaris opensource opensuse operatingsystem operatingsystems oracle os osx patents pc programming ps3 recession redhat russia sco security server servers slackware software source sun supercomputer supercomputing support suse technology tivo trends ubuntu unix users virtualization vista vmware web windows working x86 xen xml




