Linux Kernel 2.6: the Future of Embedded Computing, Part I

With the release of the 2.6 kernel, Linux's position in the embedded world has been cemented.
New Synchronization Primitives

Applications involving the use of shared resources, such as shared memory or shared devices, have to be developed carefully to avoid race conditions. The solution implemented in Linux, called Mutex, ensured that only one task is using the resource at a time. Mutex involved a system call to the kernel to decide whether to block the thread or allow it to continue executing. But when the decision is to continue, the time-consuming system call was unnecessary. The new implementation in Linux 2.6 supports Fast User-Space Mutexes (Futex). These functions can check from user space whether blocking is necessary and perform the system call to block the thread only when it is required. When blocking is not required, avoiding the unneeded system call saves time. It also supports setting priorities to allow applications or threads of higher priority to have first access to the contested resource.

Improved Threading Model and Support for NPTL

LinuxThreads, the current Linux thread library in Linux, is bad. In fact, "the fellow is as brain-damaged as LinuxThreads" is a common expression among kernel hackers. The improved threading model in 2.6 is based on a 1:1 threading model, one kernel thread for one user thread. It also includes in-kernel support for the new Native Posix Threading Library (NPTL). The kernel's internal threading infrastructure has been rewritten to allow the Native POSIX Thread Library to run on top of it.

NPTL brings an eight-fold improvement over its predecessor. Tests conducted by its authors have shown that Linux, with this new threading, can start and stop 100,000 threads simultaneously in about two seconds. This task took 15 minutes on the old threading model.

Along with POSIX threads, 2.6 provides POSIX signals and POSIX high-resolution timers as part of the mainstream kernel. POSIX signals are an improvement over UNIX-style signals, which were the default in previous Linux releases. Unlike UNIX signals, POSIX signals cannot be lost and can carry information as an argument. Also, POSIX signals can be sent from one POSIX thread to another, rather than only from process to process, like UNIX signals.

Embedded systems often need to poll hardware or do other tasks on a fixed schedule. POSIX timers make it easy to arrange any task to be scheduled periodically. The clock that the timer uses can be set to tick at a rate as fine as one kilohertz, so software engineers can control the scheduling of tasks with precision.

Subarchitecture Support

Hardware designs in the embedded world often are customized for special applications. It is common for designers to need to solve a design issue in an original way. For example, a purpose-built board may use different IRQ management than what a similar reference design uses. In order to run on the new board, Linux has to be ported or altered to support the new hardware. This porting is easier if the operating system is made of components that are well separated, making it necessary to change only the code that has to change. The components of Linux 2.6 that are likely to be altered for a custom design have been refactored with a concept called Subarchitecture. Components are separated clearly and can be modified or replaced individually with minimal impact on other components of the board support package.

By formalizing Linux's support for the slightly different hardware types, the kernel can be ported more easily to other systems, such as dedicated storage hardware and other components that use industry-dominant processor types.

Linux on Microcontrollers

In the embedded marketplace, simpler microcontrollers often are the appropriate choice when low cost and simplicity are called for. Linux 2.6 comes with the acceptance and merging of much of the uClinux project into the mainstream kernel. The uClinux project is the Linux for Microcontrollers project. This variant of Linux has been a major driver of support for Linux in the embedded market. Unlike the normal Linux ports we are accustomed to, embedded ports do not have all the features that we associate with the kernel, due to hardware limitations. The primary difference is these ports feature processors that do not feature an MMU, or memory management unit--what makes a protected-mode OS protected. Although these generally are true multitasking Linux systems, they are missing memory protection and other related features. Without memory protection, it is possible for a wayward process to read the data of, or even crash, other processes on the system. This may make them unsuitable for a multi-user system but an excellent choice for a low-cost PDA or dedicated device.

The 2.6 version of Linux supports several current microcontrollers that don't have memory management units. Linux 2.6 supports Motorola m68k processors, such as Dragonball and ColdFire, as well as Hitachi H8/300 and NEC v850. Also supported is the ETRAX family of networking microcontrollers by Axis.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

When the kernel changes, so does GLIBC & so much more.

Manish Kochar's picture

SafeSquid suffered from ugly and irritating crashes, or more appropriately - Segfaults.
With version SafeSquid 4.1.1 we have a remarkable difference, in performance.
We just had to throw away our efforts to remain complaint to older kernels, and force it to use NPTL, and the newer GLIBC, and the results are simply fantastic.

I compliment Aseem for this article, and specially the paragraph on "Improved Threading Model and Support for NPTL"

I don't where Aseem picked that comment "LinuxThreads is Brain-dead", but I can only agree that it is, and was driving us into our coffins too!

Re: Linux Kernel 2.6: the Future of Embedded Computing, Part I

Anonymous's picture

The article says "Although Linux 2.6 is not yet a true real-time operating system,[...] " and that's why the mainstream Linux kernels have a long way to go before they can be used in deeply embedded devices rather than high-end stuff like PDAs.

And then there's the memory footprint. I don't think vxWorks, eCos, RTEMS, Nucleus etc. have that much to worry about for a while yet.

Though Real-Time features are

ryotson's picture

Though Real-Time features are inserted into the kernel, the Linux as a whole is not real-time. With support for pre-emption points and new scheduler, soft real-time performance can be achieved.
Efforts were made and were also successful in deeply embeddeding the Linux. Now with the support for completely removing the VFS from Linux, we can created much compact kernel.

-- ryotson

No way

Anonymous's picture

No way. Read this, then tell me again "Linux is the future of embedded computing". It's very far from that!

Re: No way

Anonymous's picture

"However, they do not have knowledge or experience when it comes to developing or supporting tools."

Well, this phrase above fairly show us who have written that doesnt know what is saying.


Re: No way

Anonymous's picture

Arrey Asmya,
u must counter the charges this guy has presented...only then will it be a fair reading..

Re: No way

Anonymous's picture

The article is full of statements that have absolutely no data to back them up. Whilst I have never had the opportunity to code for an embedded platform, I would not base any kind of decision on an article like that. My first opinion when reading that article was that it was FUD from some company that develops tools for another embedded platform

Re: No way

Anonymous's picture

Be sure to read Kevin Dankwardt's rebuttal, sent as an open letter to the EE Times.

You may also wish to check the talkbacks posted here.


Pure FUD.

Anonymous's picture

I'm a professional commercial embedded systems developer, and there's no way I'm -NOT- going to use Linux in my projects from now on. The tools support is in fact -better- than from commercial vendors, in that i have full source for everything, the build systems available (gentoo/rock/oe) are all fully open and well-designed for the linux-kernel-hacker problems usually faced, and ... well ... the products will speak for themselves.

any 'professional' who tells you they can't use linux in their embedded product is either a) lying to you, or b) grossly incompetent.

linux is the easiest and most accessible embedded-system environment to start using!! no $15,000 'license fees' to pay before you can start building system images!!!

Re: Linux Kernel 2.6: the Future of Embedded Computing, Part I

Anonymous's picture

And the fact that Linux 2.6 integrates support for many more
hardware platforms and more I/O hardware doesn't matter at all?
I'm surprised!

For example, significant chunks of the ARM trees are now
merged, with more on the way. There's also lots of
support for some of the less mainstream I/O hardware that's
used in embedded systems ... like I2C (no longer separate),
USB Devices (the "gadget" API, contrasting to the host
side API), IPMI, and more.

In 2.4 kernels, support for hardware used on embedded
boards was a lot harder to find, unless it was basically a
cut-down PC (PC104 etc). But in 2.6, more of that is
part of the package.
That means a lot less work for anyone who wants to be
running Linux on their not-so-mainstream hardware.

Would you like tools with that?

Anonymous's picture

It's worth mentioning that
shows how to conveniently build and test a gcc and glibc
to go with the embedded Linux of your choice...