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 book.
• 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 contrary.
• 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 help.
• 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:
  http://www.embeddedtux.org/gnu-tools.html.
• "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 accurate.

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.