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?

[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?

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

Re:Why Linux?

[beelsebob]

Who cares which came first. The important thing is that that kernel is small, and has the features. Linux 2.4 does not have the features, Linux 2.6 does not have the small.

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:Why Linux?

[Anonymous Coward]

I've trimmed-down linux systems before and it was more work than my current method: start with an OpenBSD base, which is usually small enough for most purposes. Installing only the 'base' and 'etc' components results in a pretty damn tiny footprint and yet a full-featured Unix OS (and a quite stable and secure one at that).

Also, you end up with an actually supported OS that you can update every 6 months without a lot of patching and hacking around a custom forked/branched tree. I don't have time for that stuff.

And besides, OpenBSD is a joy to work with. It's so easy to admin, the system is clear and straightforward, with good (and current) documentation and easy to follow code.

Re:Why Linux?

[Anonymous Coward]

Define small, I'm working towards a first release of a Linux 2.6 based project, the Kernel + bundled busybox based RFS is 2.1M. Just saying.

Re:Why Linux?

[Lennie]

And there is also CONFIG_EMBEDDED

Re:Why Linux?

[CraigParticle]

Or just simply NetBSD [....] IMHO, build.sh is just the way to go.

Finally! I think it's amazing that we're discussing embedded systems, Linux, BSD... yet ignoring NetBSD, which is the flavor that most caters to embedded systems!

build.sh is a great example of one of those unheralded "little things". If I'm on my Mac OS X laptop and want to build a NetBSD ARM kernel or distribution for my embedded single board computer, I don't have to go fussing around with finding and downloading cross-compiling toolchains and figuring out how to make them go, etc. I just add a single flag to the normal build script that's part of the OS source code:

./build.sh -m evbarm kernel=MYKERNELCONFIG

And that's it. It will build the toolchain and then the kernel. It's so simple, it's brilliant.

NetBSD tends to get ignored a lot, but IMHO undeservedly. It is on a par with Linux 2.6 and FreeBSD in terms of speed, is flexible and feature-rich, has a nice ports/packages system and doesn't suffer from a lot of "superfluous redesign" (Linux, I'm looking at you). It's a really nice clean system and it's easy to get the basics done. It deserves more attention than it gets.

That said, the original question was "Linux 2.4 or 2.6?" If you can strip 2.6 down to fit within the confines of your embedded system, by all means go for it. This is especially true for new small x86 devices, where 2.6 is typically the baselined kernel anyway. On other architectures, it varies. On many ARM flavors, 2.6 is getting shaken out and 2.4 is still often the default. I suspect that the transition will complete this year.

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

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

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 ?

Re:New hardware new issues

[wtarreau]

Yes, 2.4.37 runs fine on an Asus EEE-Box (Atom, PCI-E, SATA, USB2, ...)

Willy

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

Re:2.6

[JamesP]

The only issue is size. 2.6 is "significantly" larger than 2.4

Really a non-issue when bigger is cheaper and smaller RAM/ROM chips are being phased out. Just as an example, we developed a product using 32MB RAM but that was phased out (really, you couldn't buy the chips anymore) in favour of 64MB RAM

How much is a 1GB usb drive today again??

I guess you need something like 2MB flash for a 2.6 system (if you really squeeze things). With 16MB/32MB you can do pretty much anything.

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.

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.

Re:GCC 2.95? Seriously?

[Brane2]

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

GCC 4 & linux 2.6

[basiles]

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

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.

Just say no to backporting (go with 2.6!!)

[cfriedt]

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.

Go 2.6

[digitalhermit]

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.

What do you want?

[RedWizzard]

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.

Re:GCC 2.95? Seriously?

[NoMoreFood]

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.

I misread the opening sentence of the article, as

[ErkDemon]

"My 6-year-old's embedded software happily runs on kernel v2.4 on an XScale CPU. ..."

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.

I'd split the difference

[Waffle Iron]

... and go with the 2.5 kernel.

God speaks ForTran IV

[Anonymous Coward]

And the Hebrew translation of the bible does it injustice.

2.6. See our Space Station project

[slashbart]

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

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.

Specific features that make 2.6 better than 2.4

[Sits]

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