Introduction
You walk into your home after a long day at work. You throw your keys on the table and plop down in front of the TV. A few seconds with the remote control and your very own I Love Lucy marathon begins.The product that automatically records any show or subject area on TV is TiVo, and the technology behind TiVo is Linux.
We increasingly live in an automated world that George Jetson would envy. We still have computers on our desktops, but over time they’ll also melt into our walls, our furniture—into the very fabric of our clothes. They’ll be so easy to use that we won’t have to learn how. Their operating procedure will be obvious from their physical design. At the heart of many of these devices will be the Linux operating system.
Invented by a Finnish college student named Linus Torvalds in the early 1990s, Linux has become the dominant Open Source computer operating system. Its influence has grown from its original “hacker” devotees to serious IT departments worldwide and recently to Wall Street. In fact,VA Linux’s stock increased 733% in value on its first day of trading—a new record for the financial world.
Why Linux?
Why is Linux so popular? And why will it be the driving force behind the embedded computer applications that will soon sweep across the world? We’ll examine several reasons in detail, but briefly these are the two most important reasons:
Linux is an Open Source operating system.
The mileage that Linux gets against other operating systems because of its Open Source nature cannot be overemphasized. The main competitor to Linux in the operating systems market is Microsoft’s Windows family of products. Many other well-funded companies have brought different (and perhaps technically superior) products to market trying to compete with Windows, and for the most part those products have failed to achieve the marketplace success that their designers had hoped for. Like Windows, all of these products were proprietary. The source code to these products was closed to the public.
The source code for Linux, on the other hand, is completely open and can be changed by anyone for any reason. You can create a product based on Linux and sell it to anyone without paying any sort of royalty.You can make any necessary changes to Linux to make your product a success in the marketplace. The only restriction is that you must share any and all changes you make to the Linux kernel with the rest of the world.
This “open source” concept really changes how computer projects—especially those at the top and bottom ends of the food chain—can be and should be designed. If you’re designing a large multiuser computer system, perhaps a large Web site, and you don’t consider a solution that involves Linux somewhere in the picture, you’re doing yourself a disservice. Ultimately, you may not choose Linux—but you should at least consider it. The same holds true for the other end of the food chain—the very small computer systems such as embedded devices. Again, you may ultimately choose another operating system for some very good reasons, but you should consider Linux mainly because of its Open Source nature and the real benefits it brings to the table.
Linux has a huge percentage of mind share, which translates into lots of momentum.
There actually is an older, and, in some ways, technically superior Open Source operating system called FreeBSD. A lot of discussion has gone into why Linux has been so successful with the development community, while FreeBSD has not enjoyed the same level of recognition. Whatever the reason, Linux has gained enormous acceptance over the last few years. That acceptance has translated into mind share, which in turn has translated into momentum, which feeds back into even greater acceptance. This beneficial closed-looped cycle is driving Linux to higher and higher levels of growth and market penetration and is the main reason that Linux is so popular today and will be here for a long time to come.
What Is an Embedded System?
Okay, now we know some very specific reasons why Linux is a good choice for operating system. I’ll come back to this subject in a bit more detail shortly, but first, it’s important to understand exactly what constitutes an “embedded” system.
User Interface
Probably the easiest way to tell the difference between an embedded system and a general-purpose computer is the user interface. A general-purpose computer usually has a monitor, keyboard, and a mouse or other pointing device attached to it. An embedded system may not have a user interface at all, or may have a more specialized primary interface such as a single button, a touch screen, or a large control panel. Embedded systems that lack a user interface may just sit listening to a network or a sensor simply gathering data, or sending and accepting commands. You may be able to plug a monitor and keyboard into an embedded system, but this isn’t the normal mode of operation. You would typically plug them in for configuration or debugging only.
Does this mean that the PCs sitting in racks at your local ISP, without monitor or keyboard, are actually embedded systems? Probably not—so it looks like we need to refine our definition a bit.
Limited Mission
The most conclusive method of determining whether a computer system fits into the “general purpose” or “embedded” category requires an examination of the system’s mission in life. Embedded systems try to be cost-effective solutions to a specific problem or specification set. A general-purpose computer’s mission is much like that of a Swiss Army knife. Like a Swiss Army knife, it ships from the factory with no clear mission. The Swiss Army knife can cut, saw, snip, screw, de-cork, tweeze, frappé. Similarly, the general-purpose computer can be used to process payroll, play Quake, surf the Internet, and more.
An embedded system has a limited mission. It might do 10 different things, but those 10 things are all it will ever do. For instance, the computer built into your car probably regulates fuel, gathers critical engine telemetry, and waits for a service technician’s commands all at the same time, but that’s all it will ever do—it doesn’t matter how powerful it is, you’re not going to play Quake on it.
Even though an embedded computer has a limited mission, that doesn’t mean that its mission can’t grow. For instance, Cisco routers can be customer-upgraded to the latest software release. Not only can bugs be fixed with the new releases, but new software can be added—expanding the usefulness of the embedded system.
Another interesting example of an embedded system’s mission growing as circumstances dictate is that of NASA’s Voyager 1 and 2 spacecraft (see www.jpl.nasa.gov/releases/97/vgrani97.html). Voyager 2, the first of the two spacecraft to be launched, began its journey on August 20, 1977. Voyager 1 was launched a few weeks later, on September 5, on a faster trajectory. Initially, both spacecraft were only supposed to explore two planets—Jupiter and Saturn. But the incredible success of those two first encounters and the good health of the spacecraft prompted NASA to extend Voyager 2’s mission to Uranus and Neptune. As the spacecraft flew across the solar system, remote-control reprogramming gave the Voyagers greater capabilities than they possessed when they left the Earth.
Anyone interested in embedded computers can find further fascinating reading online at NASA’s Web site. Check out the chapters titled “Computers On Board Unmanned Spacecraft” in www.hq.nasa.gov/office/pao/History/computers/contents.html. |
Hardware Cost/Software Complexity Ratio
We live in a time when the cost of embedded hardware components such as processors, RAM, and flash memory are falling through the floor, yet the complexity of the software required to run within embedded systems is exploding. Combined, these two trends change the rules for embedded systems engineers. Instead of simply worrying about cramming every last possible byte into a memory space stuffed full, as in years gone by, engineers must now also worry about finding time to implement all the new software features the marketplace is demanding.
This is the marketplace in which an Open Source operating system such as Linux begins to make sense. A solution based on Linux can be brought to market much more quickly than a solution that’s handcrafted from a proprietary software vendor, because many more people are working on Linux than on any proprietary vendor’s technology. The perception has been that these developers are hobbyist hackers who don’t really know how to program, but nothing could be further from the truth. Companies such as Red Hat and VA Linux are paying a lot of money to some very bright people to make sure that the Linux OS is the best it can be.
Software Cost
The most obvious—but not necessarily most important—advantage that Linux offers is that you pay no license fee, royalties, or source license fee. In fact, you pay no fees to anyone at any time for the privilege of using Linux.This can add up to a substantial savings. Commercial embeddable operating systems like those from WindRiver and QNX can cost tens of thousands of dollars just to start development, and require royalties to be paid for each product sold.
Of course, it’s important to factor into that “free” operating system the costs of developing and maintaining any changes you want to make—possibly quite long-term.
Stability
Everyone hears a lot of anecdotal evidence that Linux is very stable, especially when compared with Microsoft Windows NT. But is there any way to quantify that? Has anyone timed the frequency of the Blue Screen of Death in Windows as compared to a Linux “Oops”? The good folks at the Uptimes Project (www.uptimes.net) have done a great job trying to answer just this question. Their survey statistics showed Linux as the second most stable OS behind NetBSD and FreeBSD. As of late March 2000, the Windows NT box with the longest uptime was number 277 on the list. It had been up for 76 days. If you’ve ever run NT, you would agree that this is an amazing feat, but in contrast to the 575 days of the top Linux box or the 1,411 days of the top BSD box, there is really no comparison.
Portability
Linux has been ported to dozens of different architectures. The mainstream Linux source code itself is compatible with all of the following CPU architectures:
DEC Alpha (AXP)
The ARM and StrongARM Processors
Hitachi SuperH
IA-64
i386
Motorola 68K series
The MIPS Processor
Motorola PowerPC
S390
Sparc (32 and 64 bit)
Time to Market
The pace of technological innovation has been accelerating for the past 50 years, with no letup in sight. This is especially applicable in the computer field—where someone has even coined the phrase “Internet time” to describe the phenomenon.
On one hand, companies such as Intel and Motorola are creating new chipsets at a furious pace to compete with each other. On the other, hundreds of software and Internet companies are creating new protocols and ways of hooking computers to humans and to each other. This puts a lot of pressure on embedded OS companies such as QNX and WindRiver. They must support the hardware technologies as they first come out or soon after; then they must support those technologies long-term. The real problem for the embedded OS companies, however, is software support. They must constantly play catchup on the software front. Many of the newest software technologies are being developed using Linux, so by definition the technology is available there first. Technologies that are not developed on Linux are usually created on Microsoft Windows. Because of Linux’s huge development base, the important technologies developed on Windows are quickly migrated to Linux.
One more reason that Linux speeds time to market is that you can often use the same OS for the development host as you would for the target host.
Open Source
Except for cost, all of the reasons previously outlined are technical issues. For instance, Linux is very stable, but so are the commercial embedded OS choices. The one area that really sets Linux apart is the fact that it’s Open Source.This fact, above all technical issues, should make Linux (or perhaps some other Open Source operating system) the OS of choice until eliminated for some specific reason.
So what does it mean to be Open Source?
Version 1.7 of the Open Source Definition (www.opensource.com)
Free Redistribution
The license may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale.
Source Code
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost—preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
Integrity of the Author’s Source Code
The license may restrict source code from being distributed in modified form only if the license allows the distribution of “patch files” with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.
No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
Distribution of License
The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program’s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
License Must Not Contaminate Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be Open Source software.
Advantages of Open Source
You can find any bug when you have the source.
For developers, nothing is more frustrating than running into a wall when debugging code, or worse, when trying to debug a customer’s problem. Running into a wall means tracing your code all the way to a piece of code to which you don’t have the source and into which you therefore can’t trace, and the software fails in that code. Sometimes, the problem is in the code to which you don’t have the source, but many times it’s in your own code—perhaps you’re not correctly using the code for which you don’t have the source. It doesn’t matter—without the source, you can spend hours or even days staring at your code, and never find the problem. If you had the source code to the function you’re calling, you might quickly see what the problem is and resolve it within minutes. Or perhaps there really is a bug in the code you’re calling—you can fix it or have the maintainer fix it and get on with your work.
Many developers have resigned themselves to not seeing the source code to some of the software they’re using; they believe that these walls are just a fact of life in their chosen profession. It’s simply not true. Open Source developers who are smart enough to be able to dig deeper to the next level of code (all the way to the kernel, if necessary) simply don’t run into walls and can debug any software problem. Indeed, any problem that just can’t be solved by debugging is almost certainly a hardware problem.
You can get other people (experts) to fix code for you.
In 1999, I worked on a software application project whose users had a lot of experience with the application but none with Linux. We had to create a complete package, including a custom installation emphasizing a hardware set that our installed base of customers already had.
Several weeks into the beta cycle, a customer found a problem with a system board. Not only were we able to debug the problem all the way to the driver level, but we proposed a fix to the maintainer of the driver. He found that while this particular fix would work for our unique circumstances, a better fix was possible that would handle a whole class of problems. He implemented that fix and gave me the source code to the new driver. Had we not been working on an Open Source operating system, we would not have been able to find the problem and make a fix ourselves. Had the problem been with the driver for a generic piece of hardware for a large closed-source operating system, we would have had a difficult time getting the attention we needed and the problem might still be there.
You can find out how things are supposed to work.
Having the source code to all the drivers in Linux makes writing drivers much easier. If the code writer needs a specific feature, he or she can just look at how other drivers implement that feature. In fact, the first step when writing a new driver is usually finding a driver similar to the one you need, copying it, and then modifying the new copy for your situation.
Good documentation is available.
Some Open Source software packages are not well documented. Linux, on the other hand, is very well documented. Many free documents are available from the Linux Documentation Project, and dozens of books are available for purchase. Of course, the ultimate authority on how a software package works—the source code itself—is available for any Open Source software product.
Disadvantages of Open Source
It’s more difficult to protect intellectual property.
There are many market reasons for which you might not want to release your intellectual property: You want to get or keep ahead of the competition, you don’t own all the code your IP is based on, and so on. If you have intellectual property that you’re not planning to share with the rest of the world, you need to be very careful to not include any source code from other Open Source projects, even if you might have otherwise reduced your time to market. Including source code from (or basing your software on) other Open Source projects will generally cause your source code to be covered by the terms of that Open Source project—a bad thing for those wanting to maintain intellectual property.
For application code, there are many closed-source apps under Linux (the most notable being Netscape). In kernel space, there are many examples of binaryonly kernel modules (such as DiskOnChip, used in later examples in this book). In kernel space, though, the maintenance burden is often a very high price to pay. Since the kernel has many options that change the module interface (such as SMP versus UP, large memory model versus small, and so on), even a single kernel release may require several builds for every platform. Furthermore, kernel interfaces change, leaving the proprietor of the binary-only kernel with broken code in need of constant repair. Also, when a bug crops up, the standard set of kernel developers may refuse to help those using binary-only kernel modules and instead refer them to the modules’ proprietor.
Kernel releases come fast and furious.
Linux kernel changes can come out very quickly and can differ significantly from release to release. If you feel you must run on the latest version, this can be quite demanding.
Kernel releases don’t always appear when expected.
This can be difficult if you want to plan a release of your product based on a feature set available in the newest kernel, but don’t want to release beta code.
It’s difficult to know whether your changes will be incorporated.
If you make changes to the kernel, you can’t be sure that they’ll be incorporated into the mainline source code. Sometimes a kernel change that works perfectly is completely rejected by the kernel maintainers as being philosophically wrong for Linux. (You want them to be incorporated so that other people can do the maintenance on these changes for you when kernel interfaces change.)
Linux is not afraid of breaking backward compatibility.
Unlike other operating systems, Linux is not full of “cruft.” That is, it doesn’t have a lot of version-specific code. This makes reading the source code much easier because it’s not littered with a lot of #ifdefs# and other compatibility code. Unfortunately, this means that sometimes programs that used to run just fine under Linux may stop running with newer kernels. It’s usually up to the driver maintainer to make sure that the driver is kept up to date, so you may spend time fixing bugs where there were none earlier, because an interface changed or a service simply went away.
How the GNU Affects You
The two most important licenses you must understand if you intend to use Linux in your development project are the GNU General Public License (GPL) and the GNU Lesser General Public License (LGPL). The source code to the Linux operating system is copyrighted under the GPL, and the GNU C Library is covered under the LGPL. See Appendixes A and B for the full texts of these licenses.
How the GPL and LGPL Are Similar
Since both the GPL and LGPL are creations of the Free Software Foundation, they’re very similar. They both have the following important attributes:
Copyleft
The term copyleft, invented by the folks at the GNU project, is a pun on the word copyright. Copyleft refers to the clauses of an Open Source license that stop an individual or corporation from taking a copy of source code that’s under GPL license, making modifications, changing the license, and thereby “closing” their modified—and presumably better—version of the original source code. Once a piece of source code is placed under the GPL or LGPL, the code itself and all derivations of it are forever available in source form to any interested party. Should a third party make changes to this source code and then distribute it, they are required to make both their changes and the original source code available to anyone they distribute the software to.
Availability
If you make modifications to source code under GPL, your best bet is to get those changes folded back into the standard source set by submitting a patch to the code’s maintainer. You can usually figure out who the maintainer is by looking for a README file in the root directory of the source tar file. If your changes are accepted by the maintainer, then you’re relieved of a couple of burdens.
First, you don’t have to keep reapplying (and fixing) your patch when a new version of the code appears. This can become quite tiresome, especially if the code is released often and you want to keep up to date.
Second, the GPL requires that you accompany your product with either the source to the changes or a written offer of the source code valid for at least three years. It’s generally accepted that if your changes are available in a standard distribution, you can simply point people who want those changes to that standard distribution.
Both version 2 of the GNU General Public License and the GNU Lesser General Public License are reproduced in this book’s appendixes. If you’re considering using Linux as the operating system for your embedded application, you should take the time to read and understand these licenses. Unlike a lot of legal language, they’re quite readable and understandable from a software developer’s point of view.
How the GPL and LGPL Are Different
Licensing source code under the GPL or the LGPL produces similar results. Any changes to either code set must be made available to anyone interested, and so on.The only real difference is whether proprietary code can link with the Open Source code. The LGPL allows an entity to link its proprietary code to the Open Source code and distribute resultant binaries with no restrictions, as long as those binaries are dynamically linked. Binaries are still covered under whatever proprietary license the owner wants.
The most obvious example is the GNU C library, glibc. Since it’s released under the LGPL, a proprietary software company such as Oracle can compile and link its database application in-house, put the binaries on a CD, and ship those binaries only. Those binaries will run under the Linux kernel, which is covered by the GPL, using the dynamic glibc C libraries, which are covered under the LGPL. If Oracle decided to make changes to the C library or the Linux operating system, they would have to make those changes available to whoever wanted them, but they wouldn’t have to make the database itself public because it’s dynamically linked with the LGPL glibc.
If your entire embedded application environment is really short on space, and the entire application lives within a single executable, you may want to link it statically. If you do that and you use a library under LGPL, such as the glibc library, you’ll have to make object code or source code available to all your customers. Section 6c of the LGPL allows you to make a written offer of the object code, if you prefer. Therefore, statically linking your code can become a maintenance, support, and liability nightmare for embedded device manufacturers. I suggest dynamically linking your code so you don’t fall into this trap.
When Is Linux Inappropriate?
Which brings us to the topic of when Linux is inappropriate. Clearly, no operating system is perfect for all situations. Because Linux carries very little baggage, it covers more situations than most—but it’s not perfect for everything. You should consider the following points carefully before deciding to use Linux as the operating system for your embedded application.
You may not be able to live with the GPL.
Probably the thing that should concern an embedded developer the most is the GPL and LGPL licenses. These Open Source licenses are good things; without them, we wouldn’t even have the choice of using Linux in embedded applications—the huge growth of embedded applications would instead be much slower and limited to proprietary software. However, these licenses make it impossible to bring to market some applications based on Linux.
Linux is big.
Another area of concern for anyone looking at Linux as an embedded application operating system is its size. Even when you pull everything you can out of the OS, it’s still pretty big. If you’re building a nano-probe the size of an ant and have 100 bytes of memory to do everything, Linux is not for you. Compressed, Linux takes about 400KB. When it’s uncompressed at boot time, it’s going to take almost one megabyte. (Although uClinux can run the kernel plus a few basic user space apps in about 800KB.) For a real embedded application, the smallest realistic memory size is probably around 2MB.
Suitability.
There are some embedded applications for which other operating systems are just better suited. For instance, if you’re building a handheld PIM, it would be a lot of work to beat PalmOS in terms of functionality and size. Instead of concentrating on your application, you would have to concentrate on making the pen work, small memory management, and so on.
Security.
The debate rages on as to whether an Open Source operating system is more secure than one whose source is closed. On one hand, a bad guy who doesn’t have access to the source for your embedded application can’t stare at that source code for days trying to figure out an approach with which to attack your device. This bad guy is restricted to trying random attacks until he finds one that works, or finding general vulnerabilities in the OS you chose.
On the other hand, if the bad guy can figure out which version of Linux you’re using, he can get the source code and look for vulnerabilities. The question is, will he find one? Open Source software is considered by many to be more secure because many more eyes are looking at the code and fixing security problems.
Each argument has its merits. The bottom line is this: If you use Linux and your embedded application holds valuable data on a network, you should make sure that you can distribute security updates to your customers. Security problems will be found, and if you can’t upgrade the software on your embedded application, you’ll have problems.
Market pressures.
Of course, a vast array of nontechnical issues may require you to choose another operating system for your embedded application. Perhaps your customer or the market in general demands a particular operating system. Perhaps the investor community will pour money into your little startup if you use OS Brand X instead of Linux.
The Embedded Linux Workshop
In the pages of this book, I’ll specify the hardware for and give you the software to create your own working embedded Linux appliance. It comes complete with all the software and scripts necessary to get the machine up and working on a network—all you have to do is add the application.
Several embedded Linux development groups exist these days; all of them have some great ideas. The Embedded Linux Workshop in Chapter 7 is the minimum software necessary to embed your application. There’s no great learning curve; it’s all right there, very simple and easy to understand.
The feature set that the Embedded Linux Workshop gives you is complete enough to get you started:
It uses a floppy disk, hard drive, or flash to boot the Linux kernel and a small initrd file system.
It doesn’t require a keyboard or monitor for production. However, you can attach them for use with an optional debugging package.
It brings up a network connection.
It has an easy-to-follow procedure for adding optional packages. This way, your software doesn’t have to mingle with the Workshop’s source tree.
It has a Web-based administration package so that you can administer your appliance over the network.
The entire Embedded Linux Workshop is covered under the GPL.