×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux Kernel 2.4 Or 2.6 In Embedded System?

kdawson posted more than 5 years ago | from the comfort-on-the-trailing-edge dept.

Programming 178

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

178 comments

testing? (5, Informative)

robvangelder (472838) | more than 5 years ago | (#26319481)

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? (1)

Anonymous Coward | more than 5 years ago | (#26319749)

Don't bother answering the question, just get that first post.

Re:testing? (5, Insightful)

joaommp (685612) | more than 5 years ago | (#26320289)

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? (5, Insightful)

DuckDodgers (541817) | more than 5 years ago | (#26321223)

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? (5, Informative)

TheRaven64 (641858) | more than 5 years ago | (#26319489)

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? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26319567)

Question submitter should hire teh Torvalds to codez teh leenux's forz heez company. Leenux is good. Thats why leenux rulez teh world with an iron fist. Embed teh leenux, it takes only a little wine to makez it woozy and friendliez with youz. Leenux ridez on everythingz, it's such a hore and we likes teh horez.

Re:Why Linux? (1)

JohnFluxx (413620) | more than 5 years ago | (#26319593)

For example?

Re:Why Linux? (5, Informative)

TheRaven64 (641858) | more than 5 years ago | (#26319621)

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? (5, Interesting)

miknix (1047580) | more than 5 years ago | (#26319899)

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 [gentoo.org]

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? (1, Insightful)

Nutria (679911) | more than 5 years ago | (#26320091)

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.

Re:Why Linux? (4, Informative)

beelsebob (529313) | more than 5 years ago | (#26320233)

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? (1)

hedwards (940851) | more than 5 years ago | (#26321455)

Point being? The OP isn't developing code 5 years ago. I'm not really sure why you weren't being modded flamebait. Doubtless they were busy mismodding things with which they disagree.

But, seriously, that doesn't matter even the slightest bit, the question is whether or not to use a more up to date kernel for development. You also didn't bother to mention whether or not FBSD 5.2 was also missing those features making for a completely irrelevant and useless post.

And I'll get modded down because lets be honest, the fanbois are going to hate this.

Re:Why Linux? (3, Insightful)

Anonymous Coward | more than 5 years ago | (#26319661)

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? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26319677)

pffft. I do agree that Linux might not be good for embedded devices, but BSD? C'mon, that's practically the same.
If you need embedded devices, Minix 3 is the only way to go!! It's small, light, and has the POSIX featured you need!

Re:Why Linux? (0)

Anonymous Coward | more than 5 years ago | (#26320341)

On Minix, the poster would probably have port or write some drivers. Performance could be another possible issue when thinking about the user-mode driver code. Well, it would be an interesting experiment and a way to refactor the system even more portable. NetBSD, however, would probably be a safer (from the risk perspective) option.

Re:Why Linux? (5, Insightful)

DrDitto (962751) | more than 5 years ago | (#26319845)

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? (4, Insightful)

molarmass192 (608071) | more than 5 years ago | (#26320281)

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? (3, Informative)

Anonymous Coward | more than 5 years ago | (#26320687)

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? (0)

Anonymous Coward | more than 5 years ago | (#26321683)

an anecdotal justification at best.. "I like/am used to $OS_Y therefore it is better than $OS_Z"

Re:Why Linux? (2)

RoundSparrow (341175) | more than 5 years ago | (#26320895)

OpenWRT dev trunk is rather stable, now supports 2.6.27 and 2.6.28 (change a few vars in the makefiles). The toolchain setup is automated and works well. I had no trouble setting up on modern Ubuntu 8.10 x64 host. A lot of embedded dev seems to be inflexible about hosting platform - the makefiles of OpenWRT work well.

Runs well on 8MB of RAM with 4MB flash to boot from.

Supports a variety of target platforms, even x86. Decent package manager, and always looking for additional options.

Re:Why Linux? (1)

miknix (1047580) | more than 5 years ago | (#26320913)

Yeah.. I run Linux 2.6.22 on my HTC Wizard (TI OMAP 850 200Mhz). The only thing I feel a little overkill for it is GPE with all the GTK+ related stuff (pango, cairo ..).
GNU libc is fine also, it doesn't need uclibc.

Re:Why Linux? (1)

hedwards (940851) | more than 5 years ago | (#26321479)

I was wondering who was going to point out that Atom really isn't a very good solution for projects that aren't stuck with ia32 as their development architecture. Arm of some sort is far better for these types of applications. Better power usage, and better optimizations for things that actually matter for mobile or otherwise embedded systems.

As cool as it is, there isn't really a good reason for most people to in stall a full Linux system on an embedded system. Most of the time they just need a few relevant applications without the bloat.

Re:Why Linux? (1)

digitalunity (19107) | more than 5 years ago | (#26321699)

First, the posters device environment sounds like it has a fixed power source based on that it mediates data between an FPGA and data processing equipment. With that said, a few hundred milliamps of current isn't going to matter to anyone.

Also, I don't think anyone mentioned anything about putting a full Linux system on an embedded system. It's likely nothing more than what is minimally required, i.e. kernel, ramdisk with some basic utilities and libraries(TFTP, dhcpcd, glibc) and the client apps.

The scheduler and mmap improvements are enough to encourage 2.6 usage over 2.4. Unless there is a compelling compatibility reason to stay with 2.4, I'd say pick the newest 2.6 kernel you verified works and stick with that until you have another compelling reason to upgrade.

If you are olready doing 90% of the work... (4, Insightful)

dotancohen (1015143) | more than 5 years ago | (#26319497)

...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... (4, Insightful)

ta bu shi da yu (687699) | more than 5 years ago | (#26319517)

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... (2, Funny)

Anonymous Coward | more than 5 years ago | (#26319739)

the higher number.

Re:If you are olready doing 90% of the work... (5, Informative)

ThePhilips (752041) | more than 5 years ago | (#26319773)

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... (4, Insightful)

Enleth (947766) | more than 5 years ago | (#26319827)

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.

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

dotancohen (1015143) | more than 5 years ago | (#26321669)

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?

I have no idea. I was BSing through the teeth. I love these Linux articles where one could snag a +5 Informative by throwing some buzzwords in the right places. Hell, I even had a typo in the subject!

Re:If you are olready doing 90% of the work... (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26321245)

And by the way, if you see your mom this weekend, be sure and tell her. SATAN SATAN SATAN SATAN. Sorry, just an Orbital reference.

Move on (4, Insightful)

markus_baertschi (259069) | more than 5 years ago | (#26319505)

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 (5, Insightful)

morgan_greywolf (835522) | more than 5 years ago | (#26319687)

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 (3, Insightful)

Ruie (30480) | more than 5 years ago | (#26319507)

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 (1)

TheSHAD0W (258774) | more than 5 years ago | (#26320339)

Yup. I'd recommend picking up an Atom-based netbook, installing 2.4 on it and seeing what you can get working.

Re:New hardware new issues (4, Informative)

wtarreau (324106) | more than 5 years ago | (#26321275)

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

Willy

Re:New hardware new issues (2, Insightful)

MShook (526815) | more than 5 years ago | (#26321375)

Straight from the 2.4 maintainer: can't be better than that!

2.6 (5, Informative)

JamesP (688957) | more than 5 years ago | (#26319537)

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 (0)

Anonymous Coward | more than 5 years ago | (#26319727)

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

Whether this is significant in this case depends on the embedded hardware. Most of the embedded platforms we deal with have advanced to the point where they have sufficient RAM/ROM for the larger kernel. Unless this is a high volume/tight price point product there should be enough resources for 2.6.

Re:2.6 (3, Informative)

JamesP (688957) | more than 5 years ago | (#26319767)

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 (5, Informative)

rolfwind (528248) | more than 5 years ago | (#26319541)

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

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

Re:This article was written upon 2.6 release (1)

ThePhilips (752041) | more than 5 years ago | (#26319819)

Oh yeah. The article mentions the Just Say No: No Keyboard, No Monitor, No Wires. That was really bothersome in 2.4 times that kernel couldn't be used without video and keyboard.

Framebuffer in 2.6 is really cool, compared to old 2.4 times when it was doing some weird things without possibility to change the hardcoded behavior. We had the fun with 2.4 when due to driver problems, embedded system was mixing up LCD screens: touch screen was actually showing Linux console. [N.B. reaction of manager who first witnessed the bug was surprising - he wasn't surprised at all. He was seeing Linux console and knew that system was running Linux so having instead of touch screen Linux console appeared to him absolutely OK]. IIRC we had to use trick with fbmem to avoid that happening on target system.

iptables and more? (3, Insightful)

pipatron (966506) | more than 5 years ago | (#26319543)

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.

GCC 2.95? Seriously? (-1, Troll)

loufoque (1400831) | more than 5 years ago | (#26319555)

GCC 3.4 is quite outdated.
2.95 is just plain old. Why not code in Fortran while you're at it?

Re:GCC 2.95? Seriously? (3, Interesting)

Brane2 (608748) | more than 5 years ago | (#26319581)

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

Re:GCC 2.95? Seriously? (2, Informative)

Anonymous Coward | more than 5 years ago | (#26319777)

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.

Re:GCC 2.95? Seriously? (3, Informative)

NoMoreFood (783406) | more than 5 years ago | (#26319725)

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.

Re:GCC 2.95? Seriously? (2, Interesting)

AaronW (33736) | more than 5 years ago | (#26320927)

I have had issues with the VxWorks GCC 2.95.3 on several occasions when the compiler generated incorrect code resulting in crashes and lockups. The C code was correct, but the resulting MIPS assembly was incorrect. Each time, making slight changes to the C code would fix it, i.e. replace a for loop with a while loop. I say good riddance to VxWorks. The memory management in VxWorks 5.4 was atrocious and had to replace malloc with DLMalloc plus add a method of tracking memory usage on running systems (marking each memory block with the task and caller PC) so we could find and fix memory leaks on systems out in the field. The networking was also pretty bad in it.

God speaks ForTran IV (3, Funny)

Anonymous Coward | more than 5 years ago | (#26320279)

And the Hebrew translation of the bible does it injustice.

GCC 4 & linux 2.6 (3, Informative)

basiles (626992) | more than 5 years ago | (#26319591)

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

glibc and embedded (1, Insightful)

Anonymous Coward | more than 5 years ago | (#26320085)

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 [uclibc.org]http://buildroot.uclibc.org/ [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.

Better stick with the old and proven 2.6 (1, Informative)

Anonymous Coward | more than 5 years ago | (#26319631)

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

2.4 is not developed (3, Insightful)

Anonymous Coward | more than 5 years ago | (#26319633)

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:2.4 is not developed (1)

richlv (778496) | more than 5 years ago | (#26319891)

Re:2.4 is not developed (0)

Anonymous Coward | more than 5 years ago | (#26320075)

I doubt that many developers even have such hardware anymore that would boot properly with 2.4 kernel... It is very hard and untempting to try to fix such bugs.

I have held cciss (both hardware and the support for it in Linux) in high respect by the way. It's a bit shame if no one bothers to even take a look at that bug.

Re:2.4 is not developed (1)

TheLink (130905) | more than 5 years ago | (#26320313)

You appear to have missed an important point - the hardware boots properly on at least one older 2.4 kernel.

The sort of people who intentionally stick with 2.4.x would really want their old hardware to continue working with 2.4.x.

They're not trying to upgrade to 2.6 only to find that 2.6 doesn't support their old hardware (which reasonable people would accept).

It's not confidence inspiring given it's already been about a month and there's no response from any developer. Not even a "WONTFIX".

Just say no to backporting (go with 2.6!!) (3, Informative)

cfriedt (1189527) | more than 5 years ago | (#26319643)

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.

Embedded in volume or just custom? (2, Informative)

Kjella (173770) | more than 5 years ago | (#26319647)

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.

Re:Embedded in volume or just custom? (2, Informative)

ThePhilips (752041) | more than 5 years ago | (#26319897)

What you are talking about???

2.6 supports more hardware that 2.4 - especially embedded hardware. Several architectures in 2.6 (ARM, PPC) went through restructuring to allow easily add another board/module support.

And more importantly - for "mass market" - with 2.6 you also get much much better support from hardware vendors. In 2.4 times market was only heating up. Now, in 2.6 times, the embedded Linux market is full swing. You would be hard pressed to find H/W vendor who doesn't support Linux now - but only few of them do support 2.4 now.

If you're doing embedded systems in mass market volume, it's a matter of hardware requirements and cost per unit.

If you are talking about memory consumption, then think again. In past years I haven't seen embedded system with less than 64MB RAM. When I asked "isn't it expensive? we can run on less RAM." I got a response that when buying in any kind of volumes, 32MB or less vs. 64MB make pretty much no difference. Cheap RAM is dirt cheap nowadays.

Add here fact that 2.4 has numerous problems in its virtual memory implementation, meaning that on less RAM 2.6 would run better than 2.4. And do not forget that in 2.6 kernel is truly modular - you can't remove I believe only PCI bus support, rest is optional - you can further decrease kernel image size and its memory footprint.

Re:Embedded in volume or just custom? (0)

Anonymous Coward | more than 5 years ago | (#26321889)

A couple more that nobody mentioned:
-eXecute-In-Place: if you have more memory-backed flash (or ROM) than RAM, you can force the kernel to execute binaries directly out of the flash memory rather than copying it to RAM first. The device has to be addressable by the memory bus (these are the "Memory Technology Devices" in the kernel drivers) (ie, not a flash card on an IDE controller or USB bus or whatever else), and the flash filesystem (obviously) can't be compressed.
-initramfs and tmpfs: if you DO have more ram than flash and your embedded device doesn't need to edit/store data, this could allow you to eliminate the overhead of the block device layer entirely. The initramfs image is also merged in to the kernel, giving a single file to distribute without having to create a separate disk image.

XFS (1)

twoblink (201439) | more than 5 years ago | (#26319653)

I recommend you move to 2.6 simply for XFS..

XFS vs ext3 on weaker hardware is a world of difference..

Re:XFS (0)

Anonymous Coward | more than 5 years ago | (#26319709)

Why the hell embedded system needs XFS or ext3?
Why the hell embedded system needs FS at all?
You don't do embedding very often, do you?

Re:XFS (1)

ardor (673957) | more than 5 years ago | (#26320181)

MP3 players, set top boxes, cellphones, digital picture frames, etc. require a FS, for example.

Re:XFS (1)

andreyvul (1176115) | more than 5 years ago | (#26320809)

No FS?
Then where the hell do you store the data?
Even page offsets for files/directories for a NAND flash is a file system (very crude, but still, a FS).

Re:XFS (1)

Svartalf (2997) | more than 5 years ago | (#26321273)

Embedded systems encompass a LARGE range of systems. Some of those systems need a filesystem (such as an MP3 player or a NAS server...), some need them less, but it makes some tasks within the space easier.

Not all embedded systems are PICs or similar. Your mobile phone is an embedded device, but I'd shudder to try to code that all with "traditional" embedded techniques and practices. Same goes for a whole host of things that are considered to be embedded.

Premption, responsiveness (2, Interesting)

Thomas Charron (1485) | more than 5 years ago | (#26319665)

The largest benny for an embedded system with 2.6 is timing, really. The kernel is now, for the most part, 'almost' totally preemptable, bring sort real time to the kernel. Additionally, using RTAI Fusion, you can get hard real time. RTAI extensions have phased out support for the 2.4 kernel.

But one would have to ask, I suppose. If your just replacing a legacy component with the same thing, why change the code?

Re:Premption, responsiveness (1)

andreyvul (1176115) | more than 5 years ago | (#26320643)

Almost?
What about -rt patches?
THe problem I see is that they are stuck at 2.6.26.*, you'll have to backport stuff from 2.6.27 and 2.6.28.

Re:Premption, responsiveness (2, Insightful)

NekoXP (67564) | more than 5 years ago | (#26321251)

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.

Go 2.6 (4, Informative)

digitalhermit (113459) | more than 5 years ago | (#26319669)

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.

Re:Go 2.6 (1)

DaveV1.0 (203135) | more than 5 years ago | (#26319741)

Something that is an improvement in the server and/or desktop world may not be an improvement in the embedded world.

Re:Go 2.6 (1, Informative)

Anonymous Coward | more than 5 years ago | (#26319823)

Granted, but I'd think that for an Atom-based system, a tickless kernel would be a significant improvement. Of the generic improvements, the new scheduler might make a difference.

Other improvements that benefit embedded systems in general, but may or may not benefit the OP's use case, are: asynchronous IO, pre-emption and real-time support (although not yet fully integrated in the main tree), MMU-less operation (obviously not relevant here).

Constraints (2, Interesting)

LS (57954) | more than 5 years ago | (#26319679)

Others in this thread will adequately cover the feature differences between 2.4 and 2.6, though it sounds like 2.4 already covers your needs when it comes to functionality. This makes your question more of a management one than an engineering one.

With these types of decisions you need to look at what your constraints and requirements are, whether they be time, developer resources, product lifetime, estimated lifetime of leveraged technology (kernel 2.4 in this case), cash, etc. It sounds like you'll be doing the development yourself, but otherwise I can't tell what the rest of cycle looks like, so you need to clarify these things before making a decision.

Those are major considerations, but it gets more subtle when you consider things like how much time you'll save with future updates due to better development tools and support with a new kernel, etc., so you need to estimate also whether the time you spend up front will be saved down the line.

LS

What do you want? (4, Interesting)

RedWizzard (192002) | more than 5 years ago | (#26319699)

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.

I'd migrate, but... (2, Insightful)

SamuelRobinson (323138) | more than 5 years ago | (#26319703)

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.

scheduling (0)

Anonymous Coward | more than 5 years ago | (#26319705)

scheduling algorithm and scheduling policies are so much better in 2.6 (especially since CFS appeared mainline in 2.6.23)

seriously, don't even bother with 2.4

I misread the opening sentence of the article, as (4, Funny)

ErkDemon (1202789) | more than 5 years ago | (#26319869)

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

Times have changed... (1, Informative)

Anonymous Coward | more than 5 years ago | (#26319901)

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 [freshmeat.net] and OpenEmbedded [openembedded.org] if you're looking for the current state of the art in embedded Linux.

Yes if you have time and patience (2, Interesting)

Anonymous Coward | more than 5 years ago | (#26319941)

I constantly port the kernel and distributions for custom embedded designs for new and old hardware. It is really painful.

To go to 2.6 you have to rewrite ALL your custom drivers and the board configuration files. Yes is nicer in 2.6 - but it still has to be done. Just like we did in 2.2, 2.4 and probably again for >= 2.8.

It is a real pain that the kernel and apps change so rapidly. You regularly run into compatibility problems with:

  1. Host GCC supporting target tools
  2. Host Linux distribution supporting target tools
  3. Libraries for the target
  4. Dependencies - bloody dependencies

I recommend:

  1. Get a new harddisk with a fresh distro for the build machine.
  2. Different login for every board type with its own CROSS_COMPILE exported in .bashrc. Stops accidental bad ROM builds.
  3. Use TFTP and NFS root - they are your friends.

The port from 2.4 to 2.6 can take 2 days to 2 weeks. If you can afford 2 weeks go for 2.6.

I'd split the difference (5, Funny)

Waffle Iron (339739) | more than 5 years ago | (#26319977)

... and go with the 2.5 kernel.

Re:I'd split the difference (0)

Anonymous Coward | more than 5 years ago | (#26320183)

... and go with the 2.5 kernel.

And this was modded "interesting". Creepy.

Go with 2.6 (1)

e4m (1424229) | more than 5 years ago | (#26320033)

If you plan to modernize your toolchain and overall build process, I'd strongly encourage you to get the latest 2.6 source. Otherwise it's a wasted effort IMO. Updating everything together will get you another 6 years. Only updating partially (2.4 kernel with new build tools) may not buy you that much time.

If you have space and memory for it (1)

Nelson (1275) | more than 5 years ago | (#26320059)

I'd go with 2.6. I doubt there are any features that will substantially change anything, it does get you a bit closer to "main street" though should you start adding new stuff.

Drivers (0)

Anonymous Coward | more than 5 years ago | (#26320117)

In my experience your choice will be down to drivers, namely these two concerns:

1. Since you are porting to new hw, you will have to deal not only with new arch, but also with getting all the peripherals to work, and you get better chance at that with newest kernels.

2. If you keep some custom hardware or protocols implemented in kernel modules you'd need to port your drivers, which will take much longer for 2.6 than just arch switch.

Overall I think your idea to switch to modern x86 is quite valid. Granted I don't know your requirements like cost, quantity, time, but I find it easiest to get a cheapish workable x86 platform, stick in standard kernel, a familiar distro, start coding your stuff in a scripting language and worry about the rest only when you know you have to :)

I recommend: upgrade. (1)

rew (6140) | more than 5 years ago | (#26320119)

2.6.x has a slightly larger footprint. But as you're moving to a modern platform probably with quite enough RAM, I'd say that's not a problem.

I wouldn't do it for the features others are recommending: You have your embedded app, which already runs on 2.4, it will still run on 2.4.

However, you might encounter problems with support for peripherals on 2.4, so just going for 2.6 will be less painful.

I recommend staying with what you have, unless prodded, like now, and then doing a catchup to the most recent stuff.

2.6. See our Space Station project (4, Informative)

slashbart (316113) | more than 5 years ago | (#26320295)

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 [linuxjournal.com]

Bart van Deenen

linux2.4 is NOT proven on Atom (4, Insightful)

nchip (28683) | more than 5 years ago | (#26320319)

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:linux2.4 is NOT proven on Atom (2, Informative)

wtarreau (324106) | more than 5 years ago | (#26321551)

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.

If it ain't broke... (1)

shadoelord (163710) | more than 5 years ago | (#26320405)

You know the old saying; if it ain't broke, don't fix it. Is this a personal project? Are you going to have any serious down town moving between the two kernel bases?

I know I'm going to be unpopular for this one: Linux isn't a good operating system for all embedded needs. We're swapping out some of our main product lines from Linux (macrokernel) to smaller and more efficient microkernels.

Stay with GCC 2.95 (0)

Anonymous Coward | more than 5 years ago | (#26320437)

I have got two PCs here:
one is a 5 year old one with kernel 2.2, GCC 2.95.3, and a Suse 7.1 distribution
the other one is a brand new one with kernel 2.6, GCC 4, and Ubuntu 8.10
otherwise the hardware is comparable.

I'm tell you guys: the old PC is so fast, it's a completely different experience!

I don't know which great new features there were put in the last 5 years, but everything has gotten so bloated and slow, oh my god!

Re:Stay with GCC 2.95 (2, Informative)

Lally Singh (3427) | more than 5 years ago | (#26320795)

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*,

Obvious (1)

asciiRider (154712) | more than 5 years ago | (#26320699)

Ummmm...

If it aint broke...don't fix it.

Take your time - you're lucky - you have no real reason to rush. What you have works. Ask around (you're doing this now) - try it out. Run parallel for a while in test. Then make a nice easy switch when you have no more questions...

2.6 definitely for networking performance (1)

AaronW (33736) | more than 5 years ago | (#26320851)

I recently upgraded a piece of equipment running a Freescale 8270 that does something similar from 2.4 to 2.6.17 and the networking performance improvement was very significant. If you need better performance and lower latency, 2.6 is definitely the way to go. The old 2.4 kernel had been significantly hacked up as it was to improve performance which resulted in higher latency. The networking interrupts killed the performance unmodified. We now plan to upgrade two other CPUs from 2.4 to 2.6 after seeing these results. A lot of hacks were made to the 2.4 kernel that were no longer required for the 2.6 kernel, though I did have to port a couple kernel modules and I modified the 8270 network driver to handle NAPI.

Linux 2.6.x is fine with some tweaking (1)

sega01 (937364) | more than 5 years ago | (#26320935)

2.4.x might be a tad bit lighter, but 2.6.x can be very small with proper tweaking. 2.6.x should be noticably faster too. 2.6.27.x runs great on my 486 (16MB RAM), even with a stock kernel for my Arch Linux fork. Be sure to enable CONFIG_EMBEDED and take a look in kernel hacking :-). Cheers!

2.6 (1)

jonored (862908) | more than 5 years ago | (#26321373)

I'd swap over to 2.6 if you're swapping to a COM Express module - I'd worry about support for PCIe and devices based on it in 2.4, and the whole point of COM Express over other board designs is to get PCIe and other differential signaling. Also, 2.6 runs snappy on 64MB ram and a 300MHz PII - I don't remember seeing any COM Express modules with worse specs than that, and /certainly/ not an Atom-based one. Unless you're doing something very peculiar, the ~3MB of a 2.6 kernel on disk shouldn't hurt either; the small on-board disks for those modules I'm remembering being 512MB.

Linux 2.6 is a likely candidate... (2, Interesting)

Svartalf (2997) | more than 5 years ago | (#26321383)

As someone facing a similar situation at his day job, 2.4 is painful in some regards. In my case, 2.6 allows me to do a non-standard initramfs (the stock is minimal and then you can load other initrd or initramfs images from the kernel options...) so that I can tapdance around the three differing hackish bootloaders they did in 2.4. This allows me to do major cleanups in what they did for doing NFS rootfs on the IXP2800 blades and on the X86 ones with minimal pain.

Most of the people commenting on 2.6 being too big are thinking of the whole size with everything loaded up. Minimal kernels with just your drivers loaded and only your drivers in the module build, you end up with only about 5-10% increase in footprint in memory and store space, with the ability to provide modern device support for things. In the case of what you mention, you're moving to an Atom based machine board. Given that you're moving to a modern board, the odds of things being "nicely" supported is lower with the 2.4 kernel.

Since you're manipulating large volumes of data over GigE, you're going to want to switch, probably even with the old ARM stuff if you can manage it. 2.6 provides much more responsive networking performance (so long as you do your network code right and don't dink with the scheduler (heh...let's just say I corrected a not so good idea there recently...)).

You may have to port a few custom drivers over to 2.6, but in the end, it'll work better since the driver architecture is better in 2.6.

I'd suggest doing both, one at a time. (2, Interesting)

wtarreau (324106) | more than 5 years ago | (#26321519)

Well, it's not wise to change both the hardware and the software at the same time. You think it will reduce your time to market but it might increase it instead due to the numerous changes that will have to happen in your toolchain before getting anything barely working again.

From what I understand, you have a big experience in 2.4 and Xscale. 2.4 Also works on x86, so you'll not have to re-learn everything from scratch by just changing the architecture. All your toolchains, boot scripts, packaging scripts, etc... will still work as they did before. Then, only once you get familiar with your new architecture and the minor changes you might observe in the boot sequence, build process etc... it will be the right time to evaluate a migration to 2.6. Once you put your finger there, you'll quickly discover that you need to upgrade your gcc, glibc, replace modutils with module-init-tools, experiment with hotplug and sysfs, maybe switch to udev, etc... Step by step you'll notice a big number of changes, but you will be able to proceed one at a time, which is not possible if you change the soft at the same time as the hardware.

Also there are other aspects to consider. 2.4 has been maintained for a very long time, and you're probably used to backport some mainline fixes to your own kernel from time to time. 2.6 is not maintained that long (avg 6 months), and changes so fast that you will not be able to backport fixes for many years. I'd strongly recommend to start with 2.6.27, because Adrian Bunk will maintain it for a long time, as he did with 2.6.16. Once 2.6.27 is not maintained anymore (in about 2 years) you'll have to decide whether you stick to 2.6.27 and try to backport fixes yourself or switch to 2.6.36 (just a guess).

Also, 2.4 accepts almost no new hardware nowadays. If your new platform works well, that's fine, but how can you be sure that next year your GigE NIC will not change to something not supported anymore ?

I would say that the only case where 2.4 would make sense for a long term starting from now is if you don't have the time to revalidate 2.6 or to wait for 2.6.27 to stabilize, and need to quickly release something which will sit at your customer's in a place where it cannot be upgraded. Something like "install and forget". But I don't feel like it's what you're looking for.

So, to summarize :
      1) switch your architecture
      2) switch your kernel

Whether an official release of your product exists between 1 and 2 is just a matter of your time constraints and customer demand.

Last, to show you you're not alone, I'm too considering switching our products to 2.6, but next release will still be 2.4. Too many changes for a short-term release, and 2.6.27 not ready yet to reach years of uptime (but it's getting better though). 2.6.25 was particularly good but not maintained anymore.

Hoping this helps,
Willy

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...