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

testing?

[robvangelder]

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.

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.

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.

Why Linux?

[TheRaven64]

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?

Re:Why Linux?

[TheRaven64]

I'm assuming you're asking for examples of things that don't work correctly (or at all) in 2.4. If so, off the top of my head (it's been a couple of years since I used a 2.4 kernel):

• Lots of newer POSIX IPC (SysV IPC works okay).
• Asynchronous I/O (all of the aio_* family and lio_listio).
• Several bits of POSIX threads.
• Most of the realtime extensions, such as queued signal delivery.
• Some mmap() flags (I think - not sure about this one).

All of these work on FreeBSD 6 or 7 (aio is in a module that isn't loaded by default on 6, not sure about 7), and most of them work on Linux 2.6.

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?

[miknix]

Exactly, I would not say it better.

As a member of the gentoo embedded team I would recommend the use of crossdev to generate the toolchain.
By emerging crossdev-wrappers and setting up some gentooish cross-compiler environment, it is possible to cross-compile (by simply emerging them) a lot of packages on portage.
Emerge will take care of most things leaving the most ugly cross-compile errors for you.

http://www.gentoo.org/proj/en/base/embedded/cross-development.xml

Regarding the guide, don't use the xmerge script. Just emerge crossdev-wrappers instead.
Feel free to join #gentoo-embedded on irc.freenode.net

Happy xcompiling.

2.6

[JamesP]

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

This article was written upon 2.6 release

[rolfwind]

http://www.linuxdevices.com/articles/AT7751365763.html

Without knowing your exact parameters though, it's hard to debate any specific advantages.

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?

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

[ThePhilips]

No clue what gp meant.

From all I heard (I was in embedded business only in 2.2/2.4 times) that 2.6 integrated some number of patches from embedded folks and generally can be customized to run on smaller number of resources. Also, the improved I/O (much lower latencies) and scheduler (interactivity; soft-real-time) would benefit in embedded too. 2.4 has number of problem related to memory management, when virtual memory subsystem can easily grab half of available RAM - only for supporting virtual memory. 2.6 solved the problem for most architectures.

Generally, many embedded folks moved to 2.6 already - mainly due to support for more new OTS hardware. 2.4 has this support only through vendor patches (e.g. I used in past BlueCat and MontaVista patches).

In my experience changing kernel on embedded system is quite easy task. Using development system within couple of days you can come up with suitable minimal .config (one needs development system since on target embedded systems might not have sufficient resources to run vanilla kernel). Generally it would either work or not. Normally it works.

Also note that H/W vendors started being more active in 2.6 times. In 2.4 times best shot at Linux driver was some crude port from e.g. LynxOS or VxWorks. From all I know, 2.6 now supports more PowerPC system than did patch from MontaVista for 2.4 I used three years ago.

Last, but not least, if you are looking at new modules, many hardware vendors supply Linux compatibility information. 2 years ago finding module with "Linux compatibility" chapter in documentation wasn't a problem at all.

I'd split the difference

[Waffle Iron]

... and go with the 2.5 kernel.