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)?"
...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 ?
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++;
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.
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.
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.
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.
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.
All of these work on FreeBSD 6 or 7
v6.0 was released 5 YEARS after Linux 2.4.1 was released, so OF COURSE it has more features. Linux 2.6.1 is contemporaneous with FBSD v5.2.
"I don't know, therefore Aliens" Wafflebox1
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.
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
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.
Onda Technology Institute
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)
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.
Linux kernel preemption is about as far from real-time as you can get. It's not even in the same ballpark.
RTAI extensions do it right; it's real, real-time, although still not basically only in the parking lot outside the same ballpark. Which is as close as you need to be to HEAR the game anyway.
I don't think the guy is particularly looking for real-time support here. Pulling data over PCI-X then pushing it over a Gigabit LAN doesn't seem like it needs more than driver support. The Atom will no doubt be faster at it than his previous hardware. I'd say move to 2.6 just so you can run 2.6 and enjoy further development by someone other than yourself. Some parts of 2.6 got relatively less efficient over time (I can't say I particularly see any benefits in real-world use from the "completely fair" schedulers, for example) but in the whole driver support and general stability should be fine.
I'd stick with a kernel a few revisions back though. Don't jump in to 2.6.28. Try 2.6.25 or 2.6.26.
His solution does not require the post submitter to do any work other than to draw up a test plan.
Even before doing any coding at all, the test plan itself may reveal whether it's worth it / possible to migrate to 2.6.
I would say this more relevant to desktops and servers, rather than embedded systems (of course, it also depends on the embedded system). Embedded systems typically perform a much more limited range of operations than when used as a desktop or server.
Again, it depends on the specifics of the hardware and the application running on top of the kernel to decide which kernel is more appropriate to use.
Sleep your way to a whiter smile...date a dentist!