Say What?
|
| Author | Content |
|---|---|
| techiem2 Sep 22, 2009 7:53 PM EDT |
Yes, yes, I know. I shouldn't have even bothered. But I just HAD to see what his "solution" is.Quoting: 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. um...... |
| Alterax Sep 22, 2009 8:36 PM EDT |
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? |
| techiem2 Sep 22, 2009 8:57 PM EDT |
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. |
| Alterax Sep 22, 2009 9:23 PM EDT |
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. |
| montezuma Sep 22, 2009 10:16 PM EDT |
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.... |
| helios Sep 22, 2009 10:18 PM EDT |
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 |
| Alterax Sep 23, 2009 12:27 AM EDT |
*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. |
| Bob_Robertson Sep 23, 2009 3:55 AM EDT |
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. |
| jacog Sep 23, 2009 4:44 AM EDT |
Reminds me of that old 'Just "Photoshop" it' comic. |
| tracyanne Sep 23, 2009 4:57 AM EDT |
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. |
| mrider Sep 23, 2009 11:24 AM EDT |
(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. |
| tuxchick Sep 23, 2009 11:49 AM EDT |
mrider, it will never work. We need to pay more attention to experts like the article author. |
| mrider Sep 23, 2009 12:15 PM EDT |
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: |
| jezuch Sep 23, 2009 2:59 PM EDT |
Quoting:mrider, it will never work. We need to pay more attention to experts like the article author. Besides, Im sure it's patented. |
| bigg Sep 23, 2009 3:07 PM EDT |
Everything's patented, so that shouldn't affect design decisions. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!