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)?"

Comments

If you are olready doing 90% of the work...

[dotancohen]

...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.

Re:If you are olready doing 90% of the work...

[ta bu shi da yu]

I always hate it when people talk about improved performance in general. I'm curious about what specific features of the 2.6 kernel you feel he would benefit from?

Re:If you are olready doing 90% of the work...

[Enleth]

Much better power management, in many different aspects, which can be important if this particular embedded platform is meant to be battery-powered or used in an unfriendly thermal environment (yes, power efficiency is also a kind of performance metric, just per watt of consumed and emitted power, not per unit of time).

There's more power management support in the drivers, lots of ACPI fixes and improvements, and, most importantly for a platform like Atom (or any x86-based platform in general, when heat and power are a problem), the tickless idle mode, which enables very real and measurable power saving and reduction of generated heat by letting the processor actually do nothing (technically, drop to C3 and further power states) when, well, doing nothing, instead of processing useless interrupts and idling at the normal working power level.

Move on

[markus_baertschi]

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

Re:Move on

[morgan_greywolf]

OTOH, the code is 6 years old, and from what I gather reading the post, it's stable and mature. OTOH, my guess is that if the article poster has written his code in a fairly portable way, it will compile without too much modification on GCC 3.x or 4.x and will run under the newer versions on glibc on a 2.6 kernel.

On the gripping hand, keep in mind that for embedded applications that memory is usually at a premium and the memory footprint of 2.4 is significantly smaller than the 2.6 kernel. Keep in mind that lots of embedded applications are still using a 2.4 kernel and some embedded applications even continue to use MS-DOS or FreeDOS.

I guess if I were making this decision, I'd try to compile and run my code on newer Linux distro in a sandbox to see how much work it would take to make it compile and run in the new environment. Then I'd see how much bigger a custom-built 2.6 kernel is than the existing 2.4 kernel, optimizing the kernel configuration for size and memory consumption, of course.

That work should take no longer than a couple of days.

If it doesn't work out, you can go back to your existing 2.4 configuration. *shrug*

What do you have to lose?

New hardware new issues

[Ruie]

My question: is it worth it to jump to kernel 2.6, or better to stick with the old and proven 2.4?

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 ?

iptables and more?

[pipatron]

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.

2.4 is not developed

[Anonymous Coward]

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.

Re:Why Linux?

[Anonymous Coward]

Or just simply NetBSD, as it's cross-compilation toolchain will save you tons of headaches when you will have to compile and test your new ramdisk.

IMHO, build.sh is just the way to go.

Re:Why Linux?

[DrDitto]

2.6 is a lot better from a feature-standpoint, but is much heavier and isn't really suited to embedded systems anymore.

Lets see-- Android runs Linux 2.6.25. My Linksys NSLU2 is currently running OpenWRT with a Linux 2.6.26 kernel. Both are embedded devices with far less processing capability than an Atom-based device.

Re:Why Linux?

[molarmass192]

I was thinking the same thing. Yes, 2.6 has a bigger codebase, but if you compile only the modules you need, instead of everything plus the kitchen sink, it's really no bigger in binary form (maybe +5%). In return, I find it to be noticeably more responsive given the same hardware.

Re:testing?

[joaommp]

actually, why was this modded flamebait? despite the fact that it doesn't give a direct answer to the question (99.9% of posts don't even give any answer, direct or indirect to the questions), the post actually makes sense and is relevant. With a test plan there is the possibility to find incompatibilities that don't pop out at first sight and that may force the guy to stick to the older kernel and, thus, voiding the 'is it worth it'-question with an 'is it possible'-question.

linux2.4 is NOT proven on Atom

[nchip]

or better to stick with the old and proven 2.4?

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.

Re:testing?

[DuckDodgers]

Your solution requires the post submitter to do all of the work to create his solution for both kernels, and then compare them.

If someone asked whether to build a reasonably complex website in Python or PHP would you recommend that they build both and then performance test them? That's a lot of extra work.

In both the original post submitter's case and the hypothetical one I suggested, it would be much easier to gather as much information you reasonably can about both solutions and then make an educated guess as to the best option. I'm not sure Slashdot is the best place for his information gathering, but I understand what he is doing.