Embedded Linux Terminology
Often the hardest part of an initial learning curve is learning the specific language related to the subject. It is especially difficult when the language is not necessarily defined by any particular authority, as is the case when learning to speak German or Spanish.
The language of Linux and especially embedded Linux has evolved over time. Some terms are overloaded – the same term can have more than one meaning depending on the context. The very term “Linux” is a perfect example of such an overloaded term. Linux, of course, is the name of the kernel, nothing more. Over the years, I’ve heard many interesting questions from developers related to confusion over the terminology.
In this short article, I’ll attempt to put some clarity in the terminology used around Linux and Linux distributions. Just what exactly is a Linux distribution? Where did that term come from? Wikipedia defines a Linux Distribution as “…a member of the family of Unix-like operating systems built on top of the Linux kernel.” (http://en.wikipedia.org/wiki/Linux_distribution)
What is a Linux distribution?
Let’s be more specific. A Linux distribution is certainly more than the Linux kernel upon which it is built. A Linux distribution is a collection of software components that make up an operating system, the tools to manage it, and one might argue, the tools to modify and even rebuild it.
The origins of the term “Linux Distribution” remain a mystery at least to me. However, it is interesting to note that the term “distribution” is mentioned 19 times in the GNU General Public License version 2. (http://www.gnu.org/licenses/gpl-2.0.html). I prefer to think of the word distribution as a verb rather than a noun. Indeed, the very act of distributing a collection of open source software triggers some very specific legal requirements. So let’s redefine a Linux distribution as a collection of “packages” and tools you receive from someone or somewhere, which together make a hardware platform (and possibly a development environment, more on that in an upcoming article) come to life.
What is a package?
A package is the fundamental unit of software delivery in a Linux distribution. A software package contains anywhere from one to potentially thousands of related files. Packages are usually either source packages or binary packages. Source packages contain the source code and usually contain the build configuration and instructions to build the binary artifacts. Note that although source packages are still relatively popular formats for delivery of source code, they are seldom used as the build mechanism.
Binary packages are essentially the artifacts from building the source code packaged in a convenient form that enables easy creation of root file system images. Binary packages include any related libraries, configuration files, sample databases, and other supporting files required for basic operation of the software in a default configuration.
Packages are not just simple collections of related files. Packages exist in a special format that can be read and written by package manipulation tools. Packages come in many forms. Several popular package formats are currently in use, including .deb format from Debian, .rpm format from RedHat, and .ipk format that has become popular for embedded Linux. For example, the popular bluez package (Bluetooth protocol stack) configured for an embedded system (with docs, man pages and some test utilities removed) could contain these files:
./etc/dbus-1/system.d/bluetooth.conf ./etc/bluetooth/audio.conf ./etc/bluetooth/main.conf ./etc/bluetooth/network.conf ./etc/bluetooth/rfcomm.conf ./etc/bluetooth/input.conf ./usr/sbin/hciconfig ./usr/sbin/bluetoothd ./usr/sbin/hciemu ./usr/sbin/bccmd ./usr/sbin/hciattach ./usr/bin/dfutool ./usr/bin/rfcomm ./usr/bin/hcitool ./usr/bin/sdptool ./usr/bin/rctest ./usr/bin/ciptool ./usr/bin/l2ping ./usr/bin/l2test ./usr/lib/libbluetooth.so.3.11.5 ./usr/lib/libbluetooth.so.3 ./lib/udev/rules.d/97-bluetooth.rules ./lib/udev/rules.d/97-bluetooth-hid2hci.rules ./lib/udev/hid2hci
Note that the bluez package contains the daemon itself (bluetoothd) plus many supporting programs. It also contains configuration files and some templates (rules) to instruct the target system how to automatically configure the system for any Bluetooth devices it finds either during boot or as a result of plugging in a Bluetooth peripheral. The bluez package also contains a shared library (libbluetooth.so.3.11.5) of helper routines that provides access to low-level Bluetooth services.
Packages make up a root file system
A typical root file system for an embedded system might have between fifty and two hundred packages. A root file system for a simple console boot with networking support can be assembled with fewer than 20 packages. A full featured rootfs for a system with many services including a graphical display and multimedia capabilities might be made up of several hundred packages or more.
You might be wondering where all these packages come from. Well, we build them! There are many public repositories of binary packages, especially if you’re interested in packages for a typical x86 desktop system. Debian and Ubuntu are two examples that both maintain public repositories of pre-built binary packages. However, when you are targeting embedded systems, the choices are considerably narrowed. Most development teams building embedded Linux systems have the requirement that these packages be built locally. That’s a very non-trivial exercise! We’ll definitely cover these challenges in an upcoming post.
There are a number of build systems capable of building packages. One of the more popular build systems in use for embedded systems today lives under the Yocto project umbrella, (www.yoctoproject.org) and derives from the Open Embedded project. Components of the Yocto project can be downloaded and configured to build complete embedded Linux systems. Mentor Embedded Linux is an example of a commercially available product that contains a Yocto-derived build system and utilities to build a custom embedded Linux distribution.
We’ll expand on many of these topics in coming posts. For now, if you are reading this and have any preference for topics that might interest you, please let me know.