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
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.
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
http://www.linuxdevices.com/articles/AT7751365763.html
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
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.
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.
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.
All hope abandon ye who enter here.
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
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.
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
If you want people to stay with old code to run on their boxes, please leave GCC out of the mix.
GCC's had two major improvements over the versions:
1. Better language compliance. It matters *a*lot*. And frankly, you're not going to win an argument against that on a techie forum :-) This included a new hand-written C++ parser in g++ ~3.4 that closed out over 100 bugs at once. You don't ignore hand-written C++ parsers, they're complete bitches to do.
2. Better optimizer.
As for any library bloat, the basic C/C++ libraries are shared by nearly everyone on your system. You pay for them exactly once per running system (minus templates, but I don't know of anyone using template-heavy code on a normal Linux desktop installation).
If you were running Solaris, I'd just tell you to dtrace the system and find out what's making it slow. But, no, *sigh*,
Care about electronic freedom? Consider donating to the EFF!
Yes, 2.4.37 runs fine on an Asus EEE-Box (Atom, PCI-E, SATA, USB2, ...)
Willy
Atom is just plain x86 with HT. Nothing fancy, nothing new. Drivers for rare hardware might cause problems though, but that's true with any kernel. I would have worried if the guy wanted to switch to an exotic architecture but that's definitely not the case here.
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)...
The -rt patches do NOT a hard real time kernel make. Here's the difference. One says, 'I SHALL be called at EXACTLY this time', the other one says, 'make sure I'm called BY this time'.
-- I'm the root of all that's evil, but you can call me cookie..
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.