A first review of Building Embedded Linux Systems
by Karim Yaghmour, 09-05-2003
A first review of the book is now available online from
LinuxDevices.com. Generally, the reviewer is quite happy with the
book. He concludes by stating: "The book gives you a solid foundation
in embedded Linux that you ought to have, whether building systems using
one of the toolkits or strictly from scratch."
Having written quite a few articles and made a number of open source and
free software contributions before working on this book, I've always been
eager to get feedback on my work. As expected, I get both some positive
and some negative feedback. In this case, I think the feedback is mostly
positive, and I thank Jerry Epplin for taking the time to read the book
and share his views with others. There are, nevertheless, issues which the
reviewer raises which I think merit answering. Here are some thoughts
about Jerry's review.
First off, I'll start with the last items mentioned in the review, which
I think are the most important (most of the discussion here reflects
decisions I had to make as an author on what to include in the book):
- Omission of uClinux: I did think this through a number of times
before deciding not to cover it. Basically, developing for uClinux
requires using the modified tools and the distro provided from
uClinux.org, which made it
difficult to adapt to the book's structure (the latter is explicitely
made to help developers make it on their own without any
prepackaged toolset). I could have taken the time to provide the
required detail, but this would have had two effects: 1) add a high
degree of complexity to a first edition text; 2) seriously delay the
- Omission of RTAI/RTLinux: This was a very voluntary omission.
As many of you surely know, I've been very involved in the future of
real-time in Linux. My assessment of the situation as I was writing the
book was that Linux, and the software surrounding it, is simply not
mature enough to be able to provide the reader with a useful discussion.
There are steps in the right direction, the
Adeos nanokernel being one of them,
but we still aren't there yet. This is not to say that Linux hasn't been
used to do hard-RT before. It's just that whatever was done before is
likely to have one of two problems: 1) is legally dubious; 2) is
unlikely to be useful as a basis for future work because the entire
framework it is based on is going to change. Furthermore, providing one
single chapter on the issue would have been futile. Telling the reader
how to install RTAI or RTLinux on his kernel is certainly not that
difficult. But for any of the two to be really of any use, one has to
show the reader how to program for them, and this is where I think the
subject couldn't fit in the book without being seriously handicaped.
- Omission of GUI/framebuffer: The situation with X and the various
mini-GUIs out there is a little bit better than that of real-time, I'll
agree to that. Still, however, as with real-time, showing the reader how
to install a GUI is not that helpful without actual practical examples.
As for coding a framebuffer, that's really much better addressed in a
device drivers book, which my book isn't meant to be.
I acknowledge that many readers will notice the above omissions and will
have wished that these issues be discussed. I take note of this. As an
author, one has to decide what things can and cannot be done while still
providing the reader with useful information. My priority was to fill the
huge information gap that existed on the subject of building embedded
Linux systems. By detailing how to build an embedded Linux system without
relying an any prepackaged distribution or automated scripts, I think that
I have achieved this goal.
Less importantly, but still worthy of note, there are some aspects of the
review where the reviewer's philosphy clearly differs from that of the
book. In those cases, I think the review would have profited from leaving
it to the reader to decide which approach is best adapted to his/her
situation. Here are a few examples:
- "The subsequent chapters revisit each subject in detail without the
background material." This is true, and it's entirely intentional.
The use of Linux in embedded systems is not a trivial topic. While there
are tons of documents and scripts which try to simplify it as much as
possible, there just aren't two ways to fully understand what you are
doing. While the review clearly implies that readers don't have the time
to do it, I've structured the book for those readers who really want
to understand. This is a difference in approach. My goal was to help the
reader have it under his skin. And that means that, though he may have
to read the MTD section in Chapter 3 a few times before understanding it
all, I do think that by the time he plays around with the MTD tools, he
really ought to know it inside-out.
- On the "watchdog timers" discussion in Chapter 3. While the review
correctly states that the use of a daemon is "horribly wrong policy", I
can't be blamed for telling the reader about a software that exists.
I find it a "horribly wrong policy" as an author to avoid mentioning
problematic choices in the hopes that the reader won't make these
choices. Instead, I prefer telling the reader about what exists and tell
him what's best to do so he can make an enlightened choice. Surely this
can't be considered a technical error at any level.
- "I'm sure readers will appreciate his concern for their educational
growth, but most of us are faced with hard choices in deciding how to
spend our development time." The underlying premise here is that
using a prepackaged toolchain or a set of automated build scripts saves
the developer some time. I'm not sure that anyone can prove that this
premise is correct in regards of the GNU toolchain. From my personal
experience, and from the postings I have read on many mailing lists, the
use of scripts and binaries _may_ save some time, but the moment you hit
a snag, you will spend double, if not triple, the time to solve a
problem if the toolchain is faulty, or the build doesn't succeed in the
case of scripts. My personal belief is that learning how to build your
own toolchain will actually save you time.
- "One can only imagine a typical programmer who has installed Linux
on a desktop machine at home and develope some expertise at home ...
Imagine his/her mounting sense of panic while slogging through Chapter
4 ..." I strongly disagree with this entire paragraph. If, as the
review's introduction rightly states, embedded Linux is in "prominence
in the embedded world," then we have got to stop writing books for
amateurs. Though it can certainly be of help to them, this book is not
for amateurs. This book is for people and organizations who really want
to understand how Linux is used in embedded systems and standardize on
it. Surely such understanding and standardization comes at a price;
which is a tough learning curve in this case.
There are a few cases where I think the review can be misleading:
- Book quote: "Packaging the unmodified software for the purpose of
running it ... is not subject to this provision [requiring
distributing the source code]." This, I think, is the biggest
error in the review. Basically, the reviewer has misread what "this
provision" stands for (i.e. the text in  is incorrect). Nowhere in
my book am I implying what the reviewer assumes I am. The quote is
taken from a bulleted item list, which describes the various provisions
of the GPL, and bullet 6 of that list in particular, which is a summary
of GPLsection 2. In the context of the bullet item list, "this
provision" is bullet 6 in its entirety. In other words, the quoted
phrase says that the unmodified software is not subject to section 2 of
the GPL. In no way does that imply that "one can redistribute unmodified
GPL software without including the code", as the review states. In fact,
bullet 4, which is a summary of GPL section 3, clearly states the
- Regarding Chapter 2: "... one finds considerable filler here having
little to hold the interest of a typically harried embedded system
developers." This is unfair criticism in light of the very clear
warning I provide the reader in the "Audience of this book" section in
the Preface where I state "If you are such a reader [an experienced
embedded developer], you may want to skip some of the background
material about embedded system development ..." Clearly as an
experienced developer, I expect the reviewer to find this to be
filler. The second category of developers I list in the preface
[begining embedded system developers] will, however, find this of great
- Regarding the architecture discussion in Chapter 3: "... a
one-page summary is unlikely to be of sufficient help to a designer."
I never pretended otherwise. The introduction of this chapter
states: "Note that the following discussion does not attempt to analyze
the pros and cons of one hardware component or another. Use it, rather,
as a starting point for your research in either identifying the
components to include in your system or judging the amount of effort
needed to get Linux to run on the hardware you have already chosen."
There is no "choose your hardware" effort here, this chapter is just a
hardware support list for the interested reader. If you've followed any
mailing list related to the use of Linux in embedded systems, then
you've certainly seen the "Ok, I have an XYZ ARM board and I want to
run Linux on it, where do I start?" type of question. This is what this
chapter is for. For sure it can't provide any detail on how to use any
of the hardware it discusses in embedded Linux systems. Instead, it
provides links and resources where the reader will be able to get this
information. Rightly, some of the background info is basic, but remember
the "Audience of this book" section in the Preface.
- About the toolchain versions table: "keep this table up to date on
a web site". Sure, but that's already done:
- "Yaghmour's coverage emphasizes U-Boot, apparently reflecting his
experience with that ARM- and PPC-oriented bootloader."
Actually, the reason I chose U-Boot is that I think it's set to become
the standard bootloader for embedded Linux systems. I could have
chosen to discuss others as well, but U-Boot has a very good head-start.
The only other bootloader as complete as U-Boot that would have been
worth a discussion is RedBoot, but there's already an extensive RedBoot
manual out there and RedBoot is part of eCos ... I don't
personally like to have my bootloader be part of another OS which I'm
not going to be using in my embedded system.
Of course, there's no better way to find out if a book will be useful to
you other than by reading it. Jerry's review clearly invites you to do
just that. For my part, I hope you will enjoy the book and find it useful
in your everyday work. I also welcome any feedback and suggestions you may
have as a reader. Such input is critical for a book to remain useful and
Karim Yaghmour is the author of Building Embedded Linux
Systems, and the founder and president of Opersys inc., a
company providing expertise and courses on the use of open source and
free software in embedded systems.