Slashdot Mirror
Kernel Fork For Big Iron?
Boone^ writes: "ZDNet is running an article on the future of Linux when used on Big Iron. Just a bit ago we read about running Linux on a large scale Alpha box, and SGI wants NUMA support in Linux so it can support their hardware configuration. The article talks about how memory algorithms used with 256GB machines would hamper performance on 386s with 8MB ram. So far Linus et al have been rejecting kernel patches that provide solutions for Big Iron scaling problems. How soon before a Big Iron company forks the kernel?"
I am constantly putting Linux onto old hardware. Need a quick, dirty, and cheap NAT box? Throw Linux on a DX2/66.
MP3 file server for the geeks in IT? Throw in a big drive, but a 486 will do.
Hell, my company's web server is running on a low end PII, and I think it's a horrendous waste! It could be doing *so* much more.
Linux is a UNIX for cheap Intel hardware first. That's where its roots are, and I don't see why it should sacrifice its roots for big iron that can quite happily run a UNIX designed for big iron.
Neither does Linus, apparently.
Is this post not nifty? Sluggy Freelance. Worshi
It depends on how pervasive the code changes have to be. If it involves #ifdeffing every single file, then it's going to be very difficult to maintain that, and it's going to be very unlikely that the maintainers of the project are going to allow that feature to remain part of the major distribution.
That problem is a dual-edged sword. It also means that maintaining one big patch is a complete nightmare. Every version of the kernel that comes out has to be separately patched, with two important considerations:
- The code which needs to be inserted has to be reinserted. If this is all separate files, that's easy, but if it's not that's a complete nightmare. And the code to call into that separate file is then a nightmare.
- Any changes which have broken the patch have to be investigated and possibly changed. If you're working on filesystem patches, for example, someone working on the core fs work may have broken your patch without your knowing it, because they're not including your code in their coding/debugging process. So every time there's a change to the kernel, you have to figure out whether that change will potentially break your work.
The only way to resolve the second is to keep the patch inside the actual kernel, so that the authors of the rest of the system are aware of it, and will either try their best not to break it, or will do first-round of changing the new functionality to work with their changes.Basically, it comes down to how pervasive the work has to be. If it's a really pervasive change which touches on almost everything, then the only option from a software engineering perspective is a fork. Anything else is being done from a feel-good PR perspective, because it just doesn't make any sense from a technical perspective to try to maintain a huge patch that covers everything.
This makes it sound like Linus has been rejecting them because they provide solutions for Big Iron scaling problems. Having read kernel traffic and the linux-kernel list enough, this statement looks immediately suspicious. I have never seen Linus ever purposely reject a patch that's an all-around good fix for a problem. Usually it's "Well, Linus rejected my patch even though it does all this cool stuff and fixes all these problems, so it's probably because he just doesn't like such-and-such feature/platform/interface" and then Linus replies, "no, I rejected them because you're a dumbass and your patch sucked."
The link to the SGI page somewhat confirms this:
I just kinda heavily doubt that Linus wouldn't want awesome NUMA support if the potential was there. My best bet is that the people pushing for it just aren't on exactly the same wavelength as Linus (is anyone?) and it's slowing down progress.
Another quote that points in this direction
I don't think Linus mean any solution, just the solutions presented to him.
Even in the cases where Linus has outright rejected BigIron patches, nothing stops a hardware vendor from patching the source after the fact - almost every major Linux distribution does this now for x86/ppc/sparc etc. (NFSv3 is a great example)
I wouldn't be shocked if the stretching of boundaries that comes from:
- "Big Iron" changes, as well as
- Embedded System changes
winds up turning into there being some clear demands for forking.The fundamental problem with a fork comes in the code that you'd ideally like to be able to share between the systems. Device drivers float particularly to mind.
After a 2-way fork, it becomes necessary to port device drivers to both forks, which adds further work.
And if a given driver is only ported to one fork, and not the other, can it correctly be said that
or do we need to be forever vague about that?If you're not part of the solution, you're part of the precipitate.
Forks are usually justified only if the original maintainer pollutes the source with hacks or changes the license.
Let me clear up a few things here.
1. Earlier platforms generally had no CD-ROM.
Install via NFS or on a pre-formatted hard disk with all the necessary files. Been there, done that.
2. Earlier machines usually had a 5 1/4" floppy disk, until the late 486s started really using 3.5" floppies.
You can boot from a 5.25 floppy disk as well as from a 3.5 one. Besides from booting for the installation, there is no need at all for a floppy drive.
3. Earlier machines had RAM limitations
Many old 3/486s can use up to 16 or even 32 MB RAM. That's more than enough for a small (slow) home-sized server. Even 8 MB does the job.
4. Some earlier machines had fscked BIOSes, aside from Y2K-unfriendly BIOSes
Y2k is only an issue during boot-up, after that you can set the system's time to whatever you want. From what I've seen, Linux deals better with really old motherboards than some brand new ones.
5. Earlier machines had ISA, EISA, etc. Oh, what, you want to run GNU/Linux in something other than CGA?
There are very good SVGA cards for ISA, although running XFree with a "modern" window manager on such an old box is suicide. However, any kind of video card does the job for a "server" type of computer.
6. Earlier network cards are not all supported to get around many of these limitations
Granted, very old ISA cards might not work well, but many cards do. NE2000, old 3Com cards? No problem, work fine, and deliver good speeds too.
To make a long story short, killing support for old systems is a Bad Thing IMHO, and isn't necessary either, it would only make the kernel tarball smaller. I'm all for conditional compiles, and I actually wondered why some of the kernel patches out there (like the openwall patch) haven't been put into the mainstream kernel as 'make config' option. If they can put in accelerator thingies for Apache, why not this?
This was bound to happen sooner or later. The Linux kernel's flexibility is being taken to the limit, and people are forgetting the easiest way to improve performance for their particular rig: Customize your kernel! You can add all the code in the universe, and then you pick and choose the particular things you need or don't need! Say I run a 486/25 with 16 MB RAM as an IP Masq router. The hard drive is an old IDE with 600 megs of space. I have two network cards, and that's about it. Do I need SCSI support? Do I need to support joysticks, X, Pentiums, AX.25, or anything else? No! I compile a kernel specifically to run the IP Masq, and run it well. My P100 laptop, on the other hands needs a bit more. I use it for packet, so I need AX.25. It uses PCMCIA, so PCMCIA support needs to go in. I use XWS to run Netscape and the GIMP, so I need graphics. But, my HD is not SCSI. I yank out SCSI. My CPU is subject to the 0xf00f bug, so that gets included. I brew a custom kernel, and boot time is a lot shorter. My big-rig is a C433. I need just about everything, as I have a 3dfx card for Quake3; XWS; a SCSI scanner; and a connection to my Packet base station. I optimize compilation for the higher-end computers. I plan on getting a Cube from Apple and putting SuSE on it. Again, by optimizing the options I optimize my system. Get the point? If you want a once-size-fits-all kernel, use Windows. If you want a kernel which can be adjusted for your particular and peculiar environment, use Linux and customize your kernel! Now, for my laptop.
I used to be someone else. Now I'm someone better.
Real life is underrated.