- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
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. |
|
|
Comments (15)
Ok, I'm either woefully confused or enviably enlightened, but isn't the cafeteria-style method already being used, albeit not in XML?
I--like most other Linux users--don't have a flat monolithic kernel. I have a base kernel--including support for most of the standard I/O devices I use (and I admit, many that I don't use but are kept in the base for compatibility's sake). And there are portions of my running kernel that aren't in that base image, they are compiled seperately and loaded as kernel modules. They can be loaded and unloaded cafeteria-style, usually without interrupting the main kernel.
Personally I think that perhaps there are portions that need not be in the kernel except as add-on modules. Proprietary blobs are one hot ticket--especially in the Free Software circles--maybe we could put those into a repository of kernel objects (independent of the base kernel code) for the user or packager to compile into their own custom blends? Or support for devices that are (for lack of better words) arcane or otherwise very rare? Like the amateur radio extensions. I'm a ham radio operator--extra class, VEC, and em-comm certified no less (for those who don't know, read that as "heavily involved")--and I've yet to require any of the amateur radio extensions.
I'm not saying there is anything wrong with this code, and I'm certain that many can and do find good use for it, but due to its rarity of use I really think it should be maintained separate from the main kernel tree and modularized. Other good examples are networking protocols. Most Linux installations use a form of Ethernet rather than Token Ring. Not all, but most. Mightn't it make sense to split these off from the main code as well, since Token Ring is fading, IPv6 isn't yet widely used, and sooner or later IPv4 is likely to go away as well? ATM is nice for Linux-based routers, but most servers, desktops, laptops, embedded devices and smartphones will never use it. To me it just makes more sense to modularize these and maintain them separately.
That being said, I am no kernel programmer; these are just the ideas of a rogue tinkerer. But there are many great minds out here--would any of you all want to shrink the kernel? And if so, what are your ideas?
I--like most other Linux users--don't have a flat monolithic kernel. I have a base kernel--including support for most of the standard I/O devices I use (and I admit, many that I don't use but are kept in the base for compatibility's sake). And there are portions of my running kernel that aren't in that base image, they are compiled seperately and loaded as kernel modules. They can be loaded and unloaded cafeteria-style, usually without interrupting the main kernel.
Personally I think that perhaps there are portions that need not be in the kernel except as add-on modules. Proprietary blobs are one hot ticket--especially in the Free Software circles--maybe we could put those into a repository of kernel objects (independent of the base kernel code) for the user or packager to compile into their own custom blends? Or support for devices that are (for lack of better words) arcane or otherwise very rare? Like the amateur radio extensions. I'm a ham radio operator--extra class, VEC, and em-comm certified no less (for those who don't know, read that as "heavily involved")--and I've yet to require any of the amateur radio extensions.
I'm not saying there is anything wrong with this code, and I'm certain that many can and do find good use for it, but due to its rarity of use I really think it should be maintained separate from the main kernel tree and modularized. Other good examples are networking protocols. Most Linux installations use a form of Ethernet rather than Token Ring. Not all, but most. Mightn't it make sense to split these off from the main code as well, since Token Ring is fading, IPv6 isn't yet widely used, and sooner or later IPv4 is likely to go away as well? ATM is nice for Linux-based routers, but most servers, desktops, laptops, embedded devices and smartphones will never use it. To me it just makes more sense to modularize these and maintain them separately.
That being said, I am no kernel programmer; these are just the ideas of a rogue tinkerer. But there are many great minds out here--would any of you all want to shrink the kernel? And if so, what are your ideas?
That's always what I've thought.
When I do a streamlined kernel, I generally leave the drivers for my specific hardware and such compiled in, compile as modules other useful "stuff" I think I might want support for (but don't want built in - i.e. special usb devices and such), and remove pretty much everything else.
My main head scratching related to the article is using XML for drivers. How in the world do you define everything needed for a piece of hardware to work in a text file? Assuming it's possible, it seems to me it would be horrible to code for and would end up decreasing performance since it would essentially have to read the xml and generate/compile the module on the fly for every piece of hardware you want to use that's defined that way.
My main head scratching related to the article is using XML for drivers. How in the world do you define everything needed for a piece of hardware to work in a text file? Assuming it's possible, it seems to me it would be horrible to code for and would end up decreasing performance since it would essentially have to read the xml and generate/compile the module on the fly for every piece of hardware you want to use that's defined that way.
I'm with you on that one. XML is brilliant for the things I've used it for--mainly for making information portable between different types of data systems. But I'm just not seeing how this would be relevant or useful for binaries, especially OS-level ones.
Besides that, you're definitely right about the overhead. Parsing takes cycles, even if it is a fairly simple format. And if you're parsing the file every time a call gets made to a device, we're talking about the overhead adding up really fast.
Besides that, you're definitely right about the overhead. Parsing takes cycles, even if it is a fairly simple format. And if you're parsing the file every time a call gets made to a device, we're talking about the overhead adding up really fast.
And loadable modules the present system do exactly what is proposed. Cluelessness reaches new heights.
I have scanned all over the net on this story (the bloated kernel) and am yet to read a definitive answer on whether this bloat thing is really an issue or not. Private Intel benchmarks are supposed to show it but anecdotal evidence of people comparing kernels on desktops does not. Go figure....
I have scanned all over the net on this story (the bloated kernel) and am yet to read a definitive answer on whether this bloat thing is really an issue or not. Private Intel benchmarks are supposed to show it but anecdotal evidence of people comparing kernels on desktops does not. Go figure....
Let me bring the user-defined part of this equation on the table.
When I have 40 machines to get ready for distribution, I have to do it in the most time efficient and economical way possible. My hardware ranges from P3 1 gig chips to Xeon processors with 4 gigs of ram and Nvidia FX5700 cards.
OK...Let's race. One of you install windows with these driver sets and I will install my choice of Linux Distro...they flop back and forth between Super OS and Mint.
I can do four or five to your one.
Either the Kernel is going to be bloated or the end-user system is going to be bloated. At least in the Kernel, professionals are managing the mayhem....
h
When I have 40 machines to get ready for distribution, I have to do it in the most time efficient and economical way possible. My hardware ranges from P3 1 gig chips to Xeon processors with 4 gigs of ram and Nvidia FX5700 cards.
OK...Let's race. One of you install windows with these driver sets and I will install my choice of Linux Distro...they flop back and forth between Super OS and Mint.
I can do four or five to your one.
Either the Kernel is going to be bloated or the end-user system is going to be bloated. At least in the Kernel, professionals are managing the mayhem....
h
*LOL* That wouldn't even count as a race IMO. You'd get four to five Mint systems to our one Windows system only if certain conditions were met:
If our Windows system detects the network card and the hard drive controller out of the box (good luck with that) and if you took a decent nap somewhere in the middle. Otherwise after codecs, office software, graphics drivers, java, antivirus, personal firewall and Flash are installed--basic user stuff, really, we'd be lucky to get one Windows machine done to your TEN Mint machines.
But I see what you mean, I think--even if the kernel is bloated, is it necessarily a bad thing? I mean, I'm running the same operating system on three very different architectures. and never really have to think about them being very different machines. As far as I'm concerned, they work the same. That kind of functionality comes at the cost of more code in the kernel, but IMO it's not a bad trade-off.
If our Windows system detects the network card and the hard drive controller out of the box (good luck with that) and if you took a decent nap somewhere in the middle. Otherwise after codecs, office software, graphics drivers, java, antivirus, personal firewall and Flash are installed--basic user stuff, really, we'd be lucky to get one Windows machine done to your TEN Mint machines.
But I see what you mean, I think--even if the kernel is bloated, is it necessarily a bad thing? I mean, I'm running the same operating system on three very different architectures. and never really have to think about them being very different machines. As far as I'm concerned, they work the same. That kind of functionality comes at the cost of more code in the kernel, but IMO it's not a bad trade-off.
Obviously the original article author is not an actual programmer. Otherwise he would have known what a "loadable module" is.
Reads to me like someone who has read lots of buzzwords.
Edit: Just dawned on me (hey, it's 4am and I can't sleep) that this is the legendary "Ken Hess" I've heard about, a supposed Linux supporter who actually never has a kind word. Liar or shill, haven't decided yet.
Clearly he's been working for MS so long he really doesn't know about loadable modules.
Reads to me like someone who has read lots of buzzwords.
Edit: Just dawned on me (hey, it's 4am and I can't sleep) that this is the legendary "Ken Hess" I've heard about, a supposed Linux supporter who actually never has a kind word. Liar or shill, haven't decided yet.
Clearly he's been working for MS so long he really doesn't know about loadable modules.
Reminds me of that old 'Just "Photoshop" it' comic.
Quoting:I have scanned all over the net on this story (the bloated kernel) and am yet to read a definitive answer on whether this bloat thing is really an issue or not. Private Intel benchmarks are supposed to show it but anecdotal evidence of people comparing kernels on desktops does not. Go figure...
Rather like comparisons between fancy benchmarking tests of Con Kolivas's Scheduler and anecdotal evidence provided by ordinary desktop users.
(I know this has already been said, but I still feel compelled to chime in)
Sarcasm Mode: Yeah, I have this great idea. Instead of compiling the code for devices into the kernel, we can make them modular. Then we can compile the code for those modules, but leave them out of the running kernel until needed. Then when they are needed - we can just plug them in. Maybe we should call them pluggable modules? Yeah, that's the ticket. And then we can write a program that can intelligently add or remove a module from the running kernel without needing to reboot. Maybe we should call that modprobe. I just see so many possibilities here. It's amazing that nobody ever thought of this! /Sarcasm Mode:
Sheesh.
Sarcasm Mode: Yeah, I have this great idea. Instead of compiling the code for devices into the kernel, we can make them modular. Then we can compile the code for those modules, but leave them out of the running kernel until needed. Then when they are needed - we can just plug them in. Maybe we should call them pluggable modules? Yeah, that's the ticket. And then we can write a program that can intelligently add or remove a module from the running kernel without needing to reboot. Maybe we should call that modprobe. I just see so many possibilities here. It's amazing that nobody ever thought of this! /Sarcasm Mode:
Sheesh.
mrider, it will never work. We need to pay more attention to experts like the article author.
I don't pretend to be in anything even remotely approaching Linus' league as a programmer, but I can envision what he meant. I'm guessing that there are lots of bits of code that perform similar functions such that they could be refactored into fewer more abstract functions and similar.
So I'm guessing "bloated" means "refactoring would slim this down", not "there is too much functionality".
Sarcasm Mode: And yeah, he's an expert all right... /Sarcasm Mode:
So I'm guessing "bloated" means "refactoring would slim this down", not "there is too much functionality".
Sarcasm Mode: And yeah, he's an expert all right... /Sarcasm Mode:
Quoting:mrider, it will never work. We need to pay more attention to experts like the article author.
Besides, Im sure it's patented.
Everything's patented, so that shouldn't affect design decisions.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
um......