Slashdot Mirror
Linux Kernel 2.4 Or 2.6 In Embedded System?
snikulin writes "My 6-year-old embedded software happily runs on kernel v2.4 on an XScale CPU. The software gets a bunch (tens of megabytes) of data from an FPGA over a PCI-X bus and pushes it out over GigE to data-processing equipment. The tool chain is based on the somewhat outdated gcc v2.95. Now, for certain technical reasons we want to jump from the ARM-based custom board to an Atom-based COM Express module. This implies that I'll need to re-create a Linux RAM disk from scratch along with the tool chain. The functionality of the software will be essentially the same. My question: is it worth it to jump to kernel 2.6, or better to stick with the old and proven 2.4? What will I gain and what will I lose if I stay at 2.4 (besides the modern gcc compiler and the other related dev tools)?"
if you're migrating, no doubt you're performing tests to ensure your product is still fit.
once you have your test plan ready, determining fitness against either kernel should be straight-forward.
2.4 is horrible to work with. It's missing so many features you expect from a POSIXy system that you constantly have to find work-arounds. Having a 2.4 kernel on the cluster during my PhD was enormous pain - I'd write code on FreeBSD, copy it to the cluster, and find half the features were missing. 2.6 is a lot better from a feature-standpoint, but is much heavier and isn't really suited to embedded systems anymore. If you're building the image yourself, why not go with FreeBSD or OpenBSD and get the best of both worlds - FreeBSD if you lean more towards features, OpenBSD if you want a smaller footprint?
I am TheRaven on Soylent News
...then go with the newer kernel. 2.6 has _lots_ of improvements above 2.4. The security aspects may be of less interest in your application, but the performance probably won't be. I've always believed that it is better to regret having done something than to regret having not done it.
It is dangerous to be right when the government is wrong.
I'd move on. Not for any particular feature, but to stay closer to the mainstream for the next years. The 2.4 kernel, not for any technical reason, becomes increasingly exotic as people move on to 2.6.
You'll have to maintain your existing 2.4 skills for another decade when all others have moved.
Markus
Old and proven on a different hardware. Chances are your new hardware will have some issues (if only caused by you misunderstanding something) and then it would help to have the latest kernel that more people are using.
Also, Atom is a newer processor, perhaps with PCI Express in the chipset - does 2.4 support that ?
I had the same question asked for an embedded project 3 years ago. And it was very clear cut then
2.6 you get (off the top of my head)
-Modern drivers (including USB/Network/etc)
-Various tick rates and tickless
-More support
-Several other improvements
So really don't bother w/ 2.4
how long until
http://www.linuxdevices.com/articles/AT7751365763.html
Without knowing your exact parameters though, it's hard to debate any specific advantages.
Well, I don't have that much experience with 2.4, and how much is 'backported' from 2.6, but IIRC you can use better IP filtering tools in 2.6. And are all drivers for various hardware written to work with 2.4 as well?
It doesn't sound like you use linux hardly for anything else than for using the drivers for the NIC, so if your system works now, then there's probably no explicit reason to change. What I would worry about though, are your future needs. Even if you don't need to upgrade now, it might just be the perfect time to do it.
c++;
2.95 is/was regarded as a "golden" version for its maturity and stability.
I'm not certain that newest 4.3x is that much better on small embedded system without SSE and FPU units to be worth a swap...
I suggest both a GCC 4 compiler (probably gcc-4.2 or 4.3) and a Linux 2.6 kernel (perhaps at least 2.6.25) with a fairly recent (ie 2.6 or 2.7) GNU libc Indeed, all this perhaps uses a bit more RAM, but you'll have more RAM than before, and it bring a lot of important functionalities & improvements (including bug fixes). If you need a specialized HTTP server, consider GNU libmicrohttpd Regard & Happy New Year 2009
It's all about the Pentiums, baby.
The Web is like Usenet, but
the elephants are untrained.
http://www.linuxdevices.com/articles/AT7751365763.html
Since first 2.6 release, most of the developer force is gone from 2.4. Although officially they "support" 2.4, expect the support to be practically nonexistent when you bump into problems. No one should have even considered using 2.4 for the last couple years now. It is simply too risky.
If you foresee needing to periodically update the firmware to along with a library or app, then I would say a definitive YES - use the 2.6 kernel (assuming your device is supported).
It might also be the case that the board you would like to use is not supported in the 2.4 kernel if it's new enough - kernel developers usually don't want to waste time backporting their code if they can avoid it.
Which introduces the most important issue - backporting is a PITA!! To make a long story short, if you need to track a library or app, such as an embedded JRE, or a hardware interface that requires a kernel module inserted, playing catchup and needing to backport at the same time is an awful game of one-step-forward two-steps-back. Avoid it at all costs. Backporting is not always guaranteed to work!
The 2.4 kernel has a slightly faster boot time, while the 2.6 kernel has so many improvements that it's hard to shy away from. Do yourself a favour and go with a stable 2.6 kernel.
If you're doing embedded systems in mass market volume, it's a matter of hardware requirements and cost per unit. Then potentially staying with the 2.4 kernel may be a good choice. If what you're making is a small volume custom setup, I'd go with whatever is getting the most use and the most testing now, which is definately the 2.6 kernel.
Live today, because you never know what tomorrow brings
The largest benny for an embedded system with 2.6 is timing, really. The kernel is now, for the most part, 'almost' totally preemptable, bring sort real time to the kernel. Additionally, using RTAI Fusion, you can get hard real time. RTAI extensions have phased out support for the 2.4 kernel.
But one would have to ask, I suppose. If your just replacing a legacy component with the same thing, why change the code?
-- I'm the root of all that's evil, but you can call me cookie..
Lots of the improvements to 2.6 have probably been added to 2.4, but many come "native" to 2.6 so no outside patches are required. For example, kernel pre-emption, better scheduler, etc.. There are other intangibles too such as development time, testing, new toolchain, etc.., but you're already moving to a new processor and you'd have to do that anyway.
Sometime last year I was rebuilding some antique MIPS-based Linux from a 2.4 to a 2.6. Almost everything in the userspace was effortless (though much of it was based on Busybox); the main issue was related to some in-line assembler that took a while to figure out what it was doing. Once I did, I googled it and realized someone else had already solved a year or so ago.
So in short, no real benefit to sticking with 2.4 IMHO.
Others in this thread will adequately cover the feature differences between 2.4 and 2.6, though it sounds like 2.4 already covers your needs when it comes to functionality. This makes your question more of a management one than an engineering one.
With these types of decisions you need to look at what your constraints and requirements are, whether they be time, developer resources, product lifetime, estimated lifetime of leveraged technology (kernel 2.4 in this case), cash, etc. It sounds like you'll be doing the development yourself, but otherwise I can't tell what the rest of cycle looks like, so you need to clarify these things before making a decision.
Those are major considerations, but it gets more subtle when you consider things like how much time you'll save with future updates due to better development tools and support with a new kernel, etc., so you need to estimate also whether the time you spend up front will be saved down the line.
LS
There is a fine line between being a cultivated citizen and being someone else's crop. - A. J. Patrick Liszkie
So far all the positively moderated posts have advocated 2.6. Here's a slightly contrary view. You know 2.4. It seems to satisfy your needs. Why exactly are you considering change? Is there something 2.4 doesn't do that you want? I realise you might be asking in case there is some improvement that 2.6 may possibly provide that you've missed, but if the current setup does what you need then why would you even consider a change? My advice: stick with 2.4 unless 2.6 provides something additional that you definitely need.
There are some pretty compelling reasons to migrate, but looking at your specific application most of my favorite reasons don't apply. Since you're going to be changing your toolchain somewhat, the 2.6 migration isn't going to be that much more invasive. My reasons for wanting to change have mainly to do with filesystem improvements and USB improvements, which don't seem to have much traction for you. I'm assuming that you did your own hardware drivers for the PCI express data collection, so that shouldn't be a particularly big deal, except for having to redo for new hardware, which you have to do anyway.
So, like I said, I'd migrate but if you need to continue work with the old device for some reason I could see an argument for a continued freeze. The biggest downside to this is the larger jump you end up doing in another few years when you need to migrate for real functional reasons to some later kernel. It's always seemed easiest to me to embrace the opportunity to migrate if it makes reasonable sense.
scheduling algorithm and scheduling policies are so much better in 2.6 (especially since CFS appeared mainline in 2.6.23)
seriously, don't even bother with 2.4
Why the hell embedded system needs XFS or ext3?
Why the hell embedded system needs FS at all?
You don't do embedding very often, do you?
GCC 3.4 is quite outdated. 2.95 is just plain old. Why not code in Fortran while you're at it?
My development group is also stuck with gcc 2.9x series because it's only compiler our toolchain maker (WindRiver) supports for VxWorks 5.X. I'm guessing he's in a similar situation. I can't complain though -- we've never had an issue with it.
This system is based on an Intel Atom CPU, so it does have SSE and and FPU.
For the main architectures (x86, x86-64, ARM, and maybe PowerPC), GCC has been getting significantly better with each release. For less well-supported architectures (like Hitachi's SH series, an uncommon embedded CPU, or really old architectures like 68k), there's usually an older version of GCC that works better than the current ones.
Given that this is a new(ish) CPU, newer versions of GCC are going to support it much better than older ones.
From a kernel point of view, it's likely to be easier to get everything running on an Atom board under Linux 2.6 than 2.4, simply because 2.6 has newer drivers.
However, the application itself may not compile correctly with GCC 4, or may compile but have incorrect behaviour. Changing the C compiler is one of those things that's probably not worth the effort unless you have to, or you have a decent test suite and a good idea of how all the code works.
Of course, given that this is C, not C++, there's no reason you couldn't run Linux 2.6, compile everything except the app itself with GCC 4, and then compile the app with GCC 2.95.
If you want to minimize latency in your applications, chances are you'll like the new scheduler implemented in 2.6.23 and following. In general, 2.6 has better support for realtime (low-latency) applications: http://www.ibm.com/developerworks/linux/library/l-real-time-linux/index.html
I thought, aaaah, he's built a robust linux PC for his kid. But isn't insisting that his kiddy's first PC has a bang-up-to-date GCC compiler a little extreme?
Then I re-read it. Oops. Makes much more sense now. Not as cute, though.
Eric Baird
My company also has an XScale board which interacts with an FPGA for data collection. When the project first started it ran 2.4 (along with GCC 2.95) and generally sounds very similar to what you're doing.
Things have come a long way in the embedded Linux world since that time. Besides the TONS of additional features present in the the 2.6 kernel, I'm fairly certain you'll find that the vast majority of device vendors are only going to be writing drivers for the 2.6 tree. If you're upgrading to a new board I doubt you have a choice. Be comforted though, 2.6 is great (even for embedded XScale processors).
Your comment "This implies that I'll need to re-create a Linux RAM disk from scratch along with the tool chain" seems reminiscent of the old days where building cross compiling toolchains was a marathon. I highly recommend checking out Crosstool-Next Generation and OpenEmbedded if you're looking for the current state of the art in embedded Linux.
To go to 2.6 you have to rewrite ALL your custom drivers and the board configuration files. Yes is nicer in 2.6 - but it still has to be done. Just like we did in 2.2, 2.4 and probably again for >= 2.8.
It is a real pain that the kernel and apps change so rapidly. You regularly run into compatibility problems with:
I recommend:
The port from 2.4 to 2.6 can take 2 days to 2 weeks. If you can afford 2 weeks go for 2.6.
... and go with the 2.5 kernel.
If you plan to modernize your toolchain and overall build process, I'd strongly encourage you to get the latest 2.6 source. Otherwise it's a wasted effort IMO. Updating everything together will get you another 6 years. Only updating partially (2.4 kernel with new build tools) may not buy you that much time.
I'd go with 2.6. I doubt there are any features that will substantially change anything, it does get you a bit closer to "main street" though should you start adding new stuff.
I have done a few embedded systems using the Linux and uClinux Kernel. A couple of things to note:
Embedded tends to avoid glibc in favor of uClibc (www.uclibc.org). It is not full featured but it is a lot smaller.
When selecting a version of GCC and kernel, look at who has already has a running system for your board. You probably don't want to go through the effort to get gcc-4.2.x cross compiling and building your system if somebody already has 4.1.x doing the job.
I would take a look at buildroot http://buildroot.uclibc.org/ and see what options they have out of the box. As an engineer it is easy to want to pick the newest, most feature full version, least bugs version available and call it the "best". Remember though that one of the features is the cost and time to get it running. Your boss will not be impressed if you spend two weeks getting the newest kernel running on the board because it has fixes to sub-systems you don't use; when you could have used older kernel and had it running in an hour.
Also, keep in mind with this board, Ram and Flash cost money. If you are building a large number, the smaller kernel and flash disk are better from the cost/unit. If you are building a small number, the cost to cut you image down in size probably is not worth it.
In my experience your choice will be down to drivers, namely these two concerns:
1. Since you are porting to new hw, you will have to deal not only with new arch, but also with getting all the peripherals to work, and you get better chance at that with newest kernels.
2. If you keep some custom hardware or protocols implemented in kernel modules you'd need to port your drivers, which will take much longer for 2.6 than just arch switch.
Overall I think your idea to switch to modern x86 is quite valid. Granted I don't know your requirements like cost, quantity, time, but I find it easiest to get a cheapish workable x86 platform, stick in standard kernel, a familiar distro, start coding your stuff in a scripting language and worry about the rest only when you know you have to :)
2.6.x has a slightly larger footprint. But as you're moving to a modern platform probably with quite enough RAM, I'd say that's not a problem.
I wouldn't do it for the features others are recommending: You have your embedded app, which already runs on 2.4, it will still run on 2.4.
However, you might encounter problems with support for peripherals on 2.4, so just going for 2.6 will be less painful.
I recommend staying with what you have, unless prodded, like now, and then doing a catchup to the most recent stuff.
MP3 players, set top boxes, cellphones, digital picture frames, etc. require a FS, for example.
This sig does not contain any SCO code.
And the Hebrew translation of the bible does it injustice.
Hi
We moved our project from 2.4 to 2.6 during development, because the maximum interrupt latency of 2.6 is so much better. We needed to handle UDP packets within 20 ms. max and occasionally on 2.4 we would have a 60 or more. Going to 2.6 solved our problems immediately, even with early versions.
See this Linux Journal article for more details on our project http://m.linuxjournal.com/article/7190
Bart van Deenen
Linux 2.4 might be "proven" on your old Xscale system, but I doubt anyone else has even _tried_ to use Linux 2.4 on something as new as Atom. Linux 2.4 will also lack support for any of the peripherals of your Atom com module.
signatures pending - ansa@kos.to - (dont mail there)
You know the old saying; if it ain't broke, don't fix it. Is this a personal project? Are you going to have any serious down town moving between the two kernel bases?
I know I'm going to be unpopular for this one: Linux isn't a good operating system for all embedded needs. We're swapping out some of our main product lines from Linux (macrokernel) to smaller and more efficient microkernels.
this is my sig, there are many like it, but this one is mine.
one is a 5 year old one with kernel 2.2, GCC 2.95.3, and a Suse 7.1 distribution
the other one is a brand new one with kernel 2.6, GCC 4, and Ubuntu 8.10
otherwise the hardware is comparable.
I'm tell you guys: the old PC is so fast, it's a completely different experience!
I don't know which great new features there were put in the last 5 years, but everything has gotten so bloated and slow, oh my god!
Ummmm...
If it aint broke...don't fix it.
Take your time - you're lucky - you have no real reason to rush. What you have works. Ask around (you're doing this now) - try it out. Run parallel for a while in test. Then make a nice easy switch when you have no more questions...
No FS?
Then where the hell do you store the data?
Even page offsets for files/directories for a NAND flash is a file system (very crude, but still, a FS).
proud caffeine whore
If it ain't broke, don't fix it.
I recently upgraded a piece of equipment running a Freescale 8270 that does something similar from 2.4 to 2.6.17 and the networking performance improvement was very significant. If you need better performance and lower latency, 2.6 is definitely the way to go. The old 2.4 kernel had been significantly hacked up as it was to improve performance which resulted in higher latency. The networking interrupts killed the performance unmodified. We now plan to upgrade two other CPUs from 2.4 to 2.6 after seeing these results. A lot of hacks were made to the 2.4 kernel that were no longer required for the 2.6 kernel, though I did have to port a couple kernel modules and I modified the 8270 network driver to handle NAPI.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
I have had issues with the VxWorks GCC 2.95.3 on several occasions when the compiler generated incorrect code resulting in crashes and lockups. The C code was correct, but the resulting MIPS assembly was incorrect. Each time, making slight changes to the C code would fix it, i.e. replace a for loop with a while loop. I say good riddance to VxWorks. The memory management in VxWorks 5.4 was atrocious and had to replace malloc with DLMalloc plus add a method of tracking memory usage on running systems (marking each memory block with the task and caller PC) so we could find and fix memory leaks on systems out in the field. The networking was also pretty bad in it.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
2.4.x might be a tad bit lighter, but 2.6.x can be very small with proper tweaking. 2.6.x should be noticably faster too. 2.6.27.x runs great on my 486 (16MB RAM), even with a stock kernel for my Arch Linux fork. Be sure to enable CONFIG_EMBEDED and take a look in kernel hacking :-).
Cheers!
Embedded systems encompass a LARGE range of systems. Some of those systems need a filesystem (such as an MP3 player or a NAS server...), some need them less, but it makes some tasks within the space easier.
Not all embedded systems are PICs or similar. Your mobile phone is an embedded device, but I'd shudder to try to code that all with "traditional" embedded techniques and practices. Same goes for a whole host of things that are considered to be embedded.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I'd swap over to 2.6 if you're swapping to a COM Express module - I'd worry about support for PCIe and devices based on it in 2.4, and the whole point of COM Express over other board designs is to get PCIe and other differential signaling. Also, 2.6 runs snappy on 64MB ram and a 300MHz PII - I don't remember seeing any COM Express modules with worse specs than that, and /certainly/ not an Atom-based one. Unless you're doing something very peculiar, the ~3MB of a 2.6 kernel on disk shouldn't hurt either; the small on-board disks for those modules I'm remembering being 512MB.
As someone facing a similar situation at his day job, 2.4 is painful in some regards. In my case, 2.6 allows me to do a non-standard initramfs (the stock is minimal and then you can load other initrd or initramfs images from the kernel options...) so that I can tapdance around the three differing hackish bootloaders they did in 2.4. This allows me to do major cleanups in what they did for doing NFS rootfs on the IXP2800 blades and on the X86 ones with minimal pain.
Most of the people commenting on 2.6 being too big are thinking of the whole size with everything loaded up. Minimal kernels with just your drivers loaded and only your drivers in the module build, you end up with only about 5-10% increase in footprint in memory and store space, with the ability to provide modern device support for things. In the case of what you mention, you're moving to an Atom based machine board. Given that you're moving to a modern board, the odds of things being "nicely" supported is lower with the 2.4 kernel.
Since you're manipulating large volumes of data over GigE, you're going to want to switch, probably even with the old ARM stuff if you can manage it. 2.6 provides much more responsive networking performance (so long as you do your network code right and don't dink with the scheduler (heh...let's just say I corrected a not so good idea there recently...)).
You may have to port a few custom drivers over to 2.6, but in the end, it'll work better since the driver architecture is better in 2.6.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Well, it's not wise to change both the hardware and the software at the same time. You think it will reduce your time to market but it might increase it instead due to the numerous changes that will have to happen in your toolchain before getting anything barely working again.
From what I understand, you have a big experience in 2.4 and Xscale. 2.4 Also works on x86, so you'll not have to re-learn everything from scratch by just changing the architecture. All your toolchains, boot scripts, packaging scripts, etc... will still work as they did before. Then, only once you get familiar with your new architecture and the minor changes you might observe in the boot sequence, build process etc... it will be the right time to evaluate a migration to 2.6. Once you put your finger there, you'll quickly discover that you need to upgrade your gcc, glibc, replace modutils with module-init-tools, experiment with hotplug and sysfs, maybe switch to udev, etc... Step by step you'll notice a big number of changes, but you will be able to proceed one at a time, which is not possible if you change the soft at the same time as the hardware.
Also there are other aspects to consider. 2.4 has been maintained for a very long time, and you're probably used to backport some mainline fixes to your own kernel from time to time. 2.6 is not maintained that long (avg 6 months), and changes so fast that you will not be able to backport fixes for many years. I'd strongly recommend to start with 2.6.27, because Adrian Bunk will maintain it for a long time, as he did with 2.6.16. Once 2.6.27 is not maintained anymore (in about 2 years) you'll have to decide whether you stick to 2.6.27 and try to backport fixes yourself or switch to 2.6.36 (just a guess).
Also, 2.4 accepts almost no new hardware nowadays. If your new platform works well, that's fine, but how can you be sure that next year your GigE NIC will not change to something not supported anymore ?
I would say that the only case where 2.4 would make sense for a long term starting from now is if you don't have the time to revalidate 2.6 or to wait for 2.6.27 to stabilize, and need to quickly release something which will sit at your customer's in a place where it cannot be upgraded. Something like "install and forget". But I don't feel like it's what you're looking for.
So, to summarize :
1) switch your architecture
2) switch your kernel
Whether an official release of your product exists between 1 and 2 is just a matter of your time constraints and customer demand.
Last, to show you you're not alone, I'm too considering switching our products to 2.6, but next release will still be 2.4. Too many changes for a short-term release, and 2.6.27 not ready yet to reach years of uptime (but it's getting better though). 2.6.25 was particularly good but not maintained anymore.
Hoping this helps,
Willy
You comment belies a certain lack of knowledge. There is quite of bit of new development being done in FORTRAN today. Especially in heavy industry. Old VAXEN and Alphas are still in use with programs that were originally coded in DEC FORTRAN. When someone needs to add new functionality, it's typically written in the language used for the rest of the system.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
Nobody can answer your question if it is worth it to change operating systems because we don't understand your business. All changes have an associated cost and that must be measured in terms of value to the business. You claim to have a technical reason for changing CPUs - but is that backed by a justification for the business? I will assume so, but part of our responsibility as a professional is to always keep the business's best interest in mind.
Your second question about what you will gain or lose is definitely appropriate because that gives you the information you need to make the business decision. While everyone likes to use the latest and greatest, doing so does not always make the most business sense. Good luck!
You'd ask a 6 year old to write SIMD code by hand?
You cruel person.
Updating to a bang-up-to-date GCC with automatic vectorisation means less crying, and no more endless arguments about who broke the inline assembly.
I had completely forgotten about my near-useless Qtek 9100 (same as HTC Wizard, the slight difference being the casing, colours and market) :-D
Is it any good, or is it just as treacle-slow as the Windows implementation?
Argh, who am I kidding, I'm probably going to dig it up and have a go either way. F/OSS FTW!
As in I'm in the middle of a similar project right now... If you have drivers, go for 2.6 and make it a recent 2.6, like 2.6.26. I was very afraid of kernel bloat when we were considering a move up from 2.4.18, but the hit wasn't as bad as I feared. As others have said, maybe 5 or 10%. That can be a lot depending on your runtime system. How do you save non-volatile variables? Flash? PXE boot? Custom bootloader that boots up with an NFS-mounted root partition? We have found the initramfs boot environment of 2.6 MUCH easier to use than the initrd of 2.4. You don't even need to compile in ext2 to the kernel!
Toolchains. Toolchains are a GIGANTIC PAIN IN THE ASS. Don't be fooled by people who tell you buildroot, or openwrt or cross-tool are panaceas. They are not. You will have to do major modifications on any of them to fit your particular needs. Having said that, you're much more likely to have early success with a modern toolchain. One that uses, say, gcc 4.1.2 (or even newer). I built gcc 2.something toolchains a couple of years ago. What a nightmare trying to find support/patches/mailing list archived posts newer than a couple of years ago.
Before I get rambling on too much... I strongly recommend going to 2.6 if your hardware allows it. I also recomment using an OpenWrt-like approach to your toolchain, kernel, driver and application development system. You will have to modify it for your own situation, but having everything reproducible from source in one tree is a definite advantage.
I do embedded Linux and have done so on several generations of hardware and kernel.
There are a lot of slightly incorrect comments here about the size of the 2.6 kernel vs. 2.4. Once you know what your target hardware platform will is, and which subsystems you need, you can tailor a kernel to be usably small by configuring out the parts that you don't need. Don't need USB, or video4linux? Leave it out. Don't use modules, unless you need to control the load order, set parameters, or want to be able to swap hardware platforms, since they take up space in two places (ram disk and kernel memory).
One of the best reasons that I have for the 2.6 family is the new version of ram disk. You can almost trivially generate a run-time ram disk in the new cpio format, with a tweaked init that doesn't need to go to a disk for root, although some kind of non-volatile storage will certainly be needed.
It will be harder and more expensive to find really small RAM DIMMs for the Atom. Get a size that will be manufactured for a while. Same thing with your non-volatile storage. On a current project using a commercial board (including a GUI, commercial multi-language font set, media player, and a kernel with modules so we can move to other hardware, as needed), we've got a 512MByte DIMM for the Intel chip set with room to spare.
Another great reason for moving on is development. Have you tried to run a 2.4-based distribution on computers that you can buy today? It's doable, but painful. If you want to give your developers a (for example) Ubuntu 8.10 distro, which can be easily guested to freeze your build environment, they can run on the same kernel and libraries you do in the target for initial build and test.
Your question feels a bit of strange question to ask as surely anyone who has looked would notice a huge difference between the latest 2.6 (2.6.28) and the latest 2.4 (2.4.37).
Preemptible kernel (so lower latencies are possible)
Far more devices supported (both in terms of architectures and additional add on devices e.g. SATA support)
Better scheduler (initially made O(1) scales better under load and then fairer with CFS)
Task Control Groups
Better support for threads (schedules them in a more intelligent fashion)
Strict overcommit
Massive VM changes
Tickless/dynticks support
Asynchronous I/O support
Introduction of different I/O schedulers (deadline, cfq
Network stack improvements (faster, better under load e.g. NAPI support)
epoll support
Improved ACPI support
Network filesystem improvements
Initramfs support
There is a huge list of Linux kernel changes that happened between 2.4 and 2.5. There is also a good Linux kernel 2.5 changes page on IBM's developerworks. Kernelnewbies has an excellent summary of changes for each of the 2.6 kernels and a 2.5 changes page. LWN is also excellent for kernel news.
I hate it when people don't bother to state exactly the points they object to. What other changes (not listed above) do you think the question poster wouldn't benefit from? Follow the links to the full lists (don't just use the ones off the top of your head)...
I will explain the reasoning:
If you have an MMU, it esentially means you can use any kernel, distro, apps, etc. without really much thought involved. Therefore, you might as well use 2.6 for all the reasons aforementioned.
If you do not have an MMU, it means you more than likely have to/are using uCLinux. uCLinux, is not just a kernel, it is a whole distro. This is largly due to the fact that MMY-less kernels cannot support fork, etc. and all the apps are slightly customized.
My experience (as of a couple years ago) has been that uCLinux is not quite "up to snuff", and is a little flakey - particularly in support of the 2.6 kernel.
This may have changed in the past few years, by my experience was that 2.6 was not as well supported in uCLinux as 2.4, and I wound up going with 2.4 just to avoid various complications.
kernel hacker guide to git, git tutorial git bisect manpage, git bisect example.
It may be useful for you to read LWN's embedded nightmare prologue along with the original Embedded Nightmare article. If you have written extra drivers and can get them into the mainline kernel them the benefits of going with a new 2.6 could be big...
If your software does what it needs to do as well as you need it done, why introduce new variables unless you have to?
There are a number of improvements in 2.6 (enumerated by others here) as well as drivers for newer hardware, but unless you actually need those features, the gain for you is zero.
In any event, you're already going through the upheaval of a platform change, that's quite enough for one jump. Once you have everything validated on the new hardware, if you'd just like to move ahead, that is the time. You'll benefit from a known good reference where the only change between it and the new version is the kernel.
"New is good" works OK on desktop machines. "Well proven" is for the embedded world. Servers live somewhere in-between.
I'm not sure why anyone would choose 2.4 over 2.6, except for cases of legacy support. There have been numerous security issues and improvements which Linus has decided not to backport into 2.4. The notion that 2.6 is too heavyweight for embedded systems is just bunk - it will run rather well on cpus as slow as 40 MHz.
With 2.6, you're going to get the latest drivers, and a lot of important new technologies, especially with regard to things like wifi and USB. While I haven't looked at the Linux A/V architecture recently, IIRC, 2.6 brought a better AV framework than 2.4. (But I don't want to start a flamewar wrt to ALSA/OSS/Whatever, so I'll leave it at that).
The society for a thought-free internet welcomes you.
Basic config of the kernel will require at least 12 MB RAM. I think that if you fiddle with it for a while you can get lower but that is what you should expect. --- If you are using 2.4 kernel you can survive in 4 MB RAM. --- Something to consider. 2.4 was not THAT bad. I mean back then we were all saying how cool it was. :-)
There seem to be a few BSD tools with the aim of building smaller collections of binaries in a similar fashion to BusyBox.
You've mentioned crunchgen but there is also embutils (which can be smaller than busy box but requires dietlibc) and there also seems to be something called beastiebox (which allows different amounts of linking). Finally there is Cauldron which seems to be a collection of tools for creating embedded BSD environments.
SSDs (or anything that does rotating writes) may defeat some software file shredders.
The whole residual magnetic domain thing is up for debate with today's disks... In recent years there is apparently so little space and densities are so high very few bits can be recovered. The reasoning for this is that there have been cases where drives have been blanked and vast sums of money have been at stake but the data was not recovered (old Slashdot thread about data recovery questioning if it's possible after one pass). If you have a reliable link saying that this is to the contrary (for modern (post 2003) spinning hard disks) I would really like to see it though.
Hi,
I have been playing with some embedded systems as I have some personal projects with some colleagues to develop an embedded network based sflow/netflow collector. We have been testing a variety of architectures using development products and different tool chains etc. One of the common themes is that we have moved out entire system from 2.4 to 2.6 and newer versions of gcc etc which provided us with as much as 5% improvement in performance with no additional hardware. One of the observations we have found with our system is that the ATOM processors do not seem to be able to push network traffic nearly as quickly or efficiently as the MIPS or ARM based systems. This may well be because all of the ATOM based systems we have tested use realtek interfaces which don't seem to be able to handle the volumes of sflow/netflow we are pushing towards them. When we compare the performance to some of the ARM/MIPS combinations we have tested we get at least 20-40% higher network throughput when compared to the single core ATOM 1.6Ghz processors despite the ATOM having at least twice the raw Mhz. I would highly recommend testing the network throughput if your doing anything that requires bandwidth.
In the coming weeks I will update this post with a URL with all the information on the tests we have been conducting and the results. Its unfortunate that this post came soo soon before we had the information compiled.
I migrated a 2.4 kernel to a 2.6 kernel on an xscale embedded product about 6 months ago. ABout 1 man moths work. What no one here is mentonioning (cuase they are wankers not kernel coders) is that the 2.4 kernel did not have pre-emptive multitasking in the kernel, whereas the 2.6 kernel does. If you have written any 2.4 kernel modules that **really** needs to be taken into account when porting the thing, Else the jump is worth it...
I'm not an expert, I compiled Linux kernel only once and not on embedded system. Also I'm good at generalizing. ;)
Why do people switch to Windows Vista? Windows XP does not support some of the newest hardware. That's it, new OS runs better on new hardware. Why do people use 2.6 kernel on desktops? Old kernels do not support old hardware.
I know, computational power of embedded devices must be as small as possible to reduce energy consumption, cost, weight, whatever. I know, embedded hardware does not evolve the same way as desktop. But there is something in common. When new hardware comes out driver writers support newest OS first and old ones enter "if time permits" mode. Imagine that next year you device must support USB3 (while everything else remains the same). USB3 driver for new kernel is likely to be developed soon, usb3 driver for 2.4 may take longer. (Disclaimer: I know nothing about usb3, it is just an example).
Conclusion: Moore's Law is your friend.
My best friend is a senior developer at Bcom for embedded systems so I get quite an earful about his kernel code. They are using basically the latest Linux 2.6 kernel for various embedded cpus (2.6.21 on PPC, ARM, MIPS cores) He was talking about one of his layer 3 switches that runs one process with 300 threads and still runs like a champ with 2.6. Also, the Atom is not an embedded cpu (per say) and it runs XP fine while even doing video editing on netbooks so I think you'll be just fine with a slightly bulkier kernel. Also, the Atom has HT and 2.6 has much better smp support than 2.4. I would go with the Gentoo advice posted earlier and that way you can transition good and also account for the future when you have to port this thing all over again. Who knows where 2.4 will be at that point.
||| I still can't believe Parkay's not butter.
Epigrams of programming:
120 Adapting old programs to fit new machines usually means adapting new machines to behave like old ones.
( http://www.pam1.bcs.uwa.edu.au/~michaelw/Perlis_Epigrams.html )
“Our opponent is an alien starship packed with nuclear bombs. We have a protractor.” — Neal Stepnenso
And for those kind words I'm going to post a follow up to my original post of more relevant changes between the 2.4 and latest 2.6 kernels (I'll try and add a few more words after each point).
Kernel configuration was overhauled. Outside support for more GUI menus, it now means you no longer have to do make dep after changing something. Further building modules outside the kernel tree is now not so baroque. The time to build and partially rebuild kernels also dropped. Building a kernel in parallel (i.e. using more than one CPU during the build process) works better.
Better support for configuring out unneeded parts of the core kernel on embedded systems. You can see the seeds of this going mainline in a git commit on 2.5.70. There is an outside project called Linux Tiny that produces patches aimed at being able to configure out features not needed for embedded systems. Over the course of 2.6 many of these patches have trickled into the mainstream kernel.
I mentioned that 2.6 scales better under load in my previous post. Here are some benchmark comparison graphs of 2.4 versus 2.6 kernels (the graphs also include comparisons against the BSDs but you can see that Linux 2.4 had some serious problems that Linux 2.6 addressed).
The kernel is now (on systems where there is reliable device discovery) able to automatically load the modules it needs to drive hardware. No more having to adjust static lists of which modules need to be loaded.
udev was introduced. This change meant that the entries in /dev were no longer static. In 2.4 all possible device entries (even for devices you didn't have) were shown in /dev and their major/minor numbers were fixed (which was causing problems as new devices were turning up - what major/minor number do you give them?). Additionally the other dynamic /dev system (devfs) was whittled away and killed off.
FUSE support (LWN article about FUSE). Allows filesystem drivers to be written in userspace. Currently the best Linux NTFS driver is written using FUSE and it allows fun things like sshfs. Might be handy if you need users to be able to configure where data is stored remotely, you are writing your own filesystem or you need to support writing to NTFS formatted USB disks...
There is better CFS (Samba/SMB/Windows File Sharing) support. NFS version 4 support was also added.
cpufreq support. The kernel can clock down the CPU speed (usually by changing voltages via some hardware interface) to save large amounts of power. This can be done in response to work load so you run at full speed as often as possible and then when things are quiet you scale down to the lowest setting (you often save the most power when doing absolutely nothing so it pays to finish things as quickly as possible).
Any switch from 2.4 to 2.6 will of course require userspace changes (updated modutils, udev, later gcc, later glibc).
There is also davej's post Halloween document discussing changes from 2.4 to 2.5. This is very detailed and is another excellent reference.
Many many other things have changed too (e.g. ALSA support for sound has been added) but I have tried to keep the ones mentioned at least tangentially related to the original scenario :)
(After reading this and another comment I posted another follow up)