The following is a list of frequently asked questions and answers related to the The Linux Programming Interface.
Writing TLPI took several years, although the project was somewhat interrupted by various life events. The book was largely complete by 2006 (modulo subsequent updates that were required to cover features that appeared in subsequent kernel releases), but it was only in 2009 that I was able to make the time complete the task of production with No Starch Press. That task—spanning phases such as copyediting, typesetting, and proofing 1550 pages—turned out to be enormous in itself.
I had various motivations for writing TLPI, among them the facts that I enjoy properly understanding things, and love teaching (I had been a teacher in various previous jobs, and have returned to training again nowadays). I've also always enjoyed writing; I've always felt that the software projects I've worked on over the years weren't complete if I hadn't documented my work on them. In addition, some years after my first degree in Computer Science, I did an Arts degree (Psychology and Art History) that considerably honed my writing skills.
TLPI was published in 2010. Since then, the kernel and GNU C library have changed, but only slowly. (I track the changes on my API changes page.) In the meantime, all of the information in TLPI remains current, since the kernel and glibc maintainers place a strong emphasis on maintaining backward compatibility. The rate of additions to the APIs is slow enough that it will be quite a while yet before a new edition of TLPI is warranted.
This FAQ typically comes from someone wondering "should I wait for the next edition before I buy a copy of TLPI?". My answer is "no", because TLPI is still fairly current and it will be quite some time before a second edition appears.
The following will suffice:
- A reading knowledge of C (or C++). I tend to avoid esoteric features of C in my code examples, so it is not necessary to be an expert in the language.
- A basic knowledge of the shell and common Linux or UNIX commands.
I assume you have some prior programming experience, but no previous system programming experience is required.
Sorry, I can't. I've got a lot of calls on my free time. Try sending your question to a suitable mailing list or forum (e.g., StackOverflow, which these days does seem to be the true to successor to Usenet groups); using a public forum is likely to get a wide variety of useful answers, and has the advantage that others can benefit from reading the answers. Alternatively, explaining your code to a colleague, classmate, friend, or rubber duck is usually a highly effective way of improving or debugging a program.
Not at this stage, and this is unlikely to change in the foreseeable future. There are various reasons for this. One is that constructing well-made online video training materials is a lot of work, and I'm not sure if there's a revenue model that justifies the work. But, perhaps even more important: I really enjoy doing training in a face-to-face setting (and I'm fairly convinced that it can be more effective than other methods, when it is well done).
Sorry, but, no, I can't. I'm the author of the book. The publisher is the (only) one with first sale and distribution rights (for printed and ebook formats). The publisher, No Starch Press, does offer a deal to purchase the printed and ebook versions together, but that deal does not apply for printed books sold by retailers. (As far as I know, none of the retailers offer combined book-plus-ebook deals.)
On 22 July, 2011, Linus Torvalds released Linux 3.0. However, all that changed was the kernel numbering scheme (from 2.6.x to 3.x). The kernel development process itself didn't change, and, in terms of API changes, Linux 3.0 was no more significant than the preceding 2.6.39 release. A similar comment applies regarding the release of Linux 4.0 on 12 April 2015: this was a release that followed the normal pattern, but the major version was bumped from 3 to 4.
As a general principle, existing Linux kernel-user-space interfaces are never changed (since doing so would break ABI-compatibility). In terms of API changes, all that normally changes with each kernel release (every 2 to 3 months) is extensions to existing interfaces or the addition of new interfaces (e.g., new system calls). Furthermore, the pace of changes in the kernel-user-space API is quite slow (relative to the hectic pace of changes inside the Linux kernel).
All of the above is to say, "No, the release of Linux 3.0 (or 4.0 or 5.0 or 6.0) doesn't render TLPI out-of-date". I expect readers will still be finding the current edition of TLPI useful many years after publication.
If you want to get an idea of what has changed in the kernel-user-space API since TLPI was published, see the API changes page.
Here, I'll simply quote from the preface of TLPI:
Although I focus on Linux, I give careful attention to standards and portability issues, and clearly distinguish the discussion of Linux-specific details from the discussion of features that are common to most UNIX implementations and standardized by POSIX and the Single UNIX Specification. Thus, this book also provides a comprehensive description of the UNIX/POSIX programming interface and can be used by programmers writing applications targeted at other UNIX systems or intended to be portable across multiple systems.
One or two people have commented that they would have liked more exercises in TLPI.
To begin with, it's worth noting that there are a lot of exercises in TLPI—more than 200. However, there are also 64 chapters, which means that some chapters only have one or two exercises.
Coming up with good, nontrivial exercises is quite a bit of work. I did put quite some effort into writing exercises for TLPI. But in retrospect, it's clear that, for some readers, it would have been valuable to have even more exercises, and it would have been worthwhile to invest even more time in the task of creating exercises. Suggestions for further exercises are welcome; I can blog about them and/or include them in a future edition of TLPI.
Some people have made suggestions for larger changes to the text of TLPI. Although some of the proposed ideas are good, it usually isn't possible to make such changes. The reason that this isn't possible is that it would result in reflow of the text, changing the fall of page breaks in the following pages of a chapter. Aside from the sheer work involved (doing good page layout is surprisingly hard), such substantial changes would mess up index entries (page numbers would be out of sync) and (less significantly) would change page numbering in the table of contents.
Notwithstanding the fact that substantial changes can't be made to this edition of TLPI, I am collecting the ideas that are being proposed for inclusion in a future edition of TLPI.
Some people have asked why I didn't cover various other topics in TLPI (e.g., more socket options in Chapter 61, tracing and debugging techniques, POSIX AIO).
The general answer to this question is twofold: time and space. There are various additional topics I myself would have liked to include in TLPI, but in the interest of actually finishing the book, I had to draw the line somewhere, and exclude those topics. In addition, as we headed toward production, it became clear that we were going to run close to the limits of what could be printed as a single paper volume (the publisher and I both agreed that we didn't want to go to two volumes). Thus, there wasn't enough space to cover every desirable topic.
When there is one day a second edition of TLPI, we may well go to two volumes and go into greater detail on some topics and add various topics not covered in the first edition. I'm collecting suggestions for topics to consider for inclusion in future editions of TLPI, if you want to send me specific suggestions.
For the general answer, see Why isn't topic X covered?.
With respect to AIO specifically, there were additional reasons. There are various criticisms regarding whether the API is fit-for-purpose. Furthermore, the current Linux implementation is a user-space threads-based implementation that scales poorly when large numbers of I/O operations are involved. (There has been some work done towards a properly performing, state-machine-based kernel implementation of asynchronous I/O, but this work is as yet incomplete, and currently seems to be stalled. Some out-of-date information on the work can be found at the SourceForge page Kernel Asynchronous I/O (AIO) Support for Linux.) In summary, it's not clear that the current (Linux) POSIX AIO interface is widely used.
For these general and specific reasons, I didn't describe POSIX AIO (beyond a mention on page 1327). This is a topic that might be added in a second edition of TLPI. In the meantime, since writing TLPI, I wrote some additional manual pages for POSIX AIO (to supplement those already written by Andries Brouwer). You can find these pages by starting at the aio(7) page.
There are many conventions for identifiers in C, with underscore-separators (a common and early convention, and the one used in the kernel-user-space API and in the Linux kernel source code) and CamelCase (made popular in the X libraries) being among the more common. I'm not religiously attached to any particular convention. In the book, I happened to use CamelCase for most identifiers (other than constants, which are normally in all-caps with underscores where appropriate). CamelCase has a small virtue for the example programs: when the reader sees a CamelCase identifier, it's immediately clear that it is one of my identifiers, not a standard system identifier.
To begin with, an obvious point: every book contains typographical or technical errors.
By now, the errata page has become quite long. One reason that there are a lot of errata is that there is a lot of book: 1550 pages. Another reason is that I'm very conscientious about fixing and documenting all errors that I find or that are reported to me (by contrast, a lot of books don't even maintain an errata list), and I've tried to make it very easy for readers to report errors.
The observation that there are a lot of errata also needs to be tempered with some analysis. The 615 errata documented as at September 2022 can be broken down (see the coding on the errata page) as follows (the numbers inside parentheses are the figures for the errata that have not yet been applied in the latest print run):
- 9 (0) fixes to significant code problems.
- 1 (0) significant fix to an explanation in the text.
- 11 (0) significant fixes to technical details explained in the text.
- 75 (0) minor code fixes. The corresponding code problem is minor and its solution is normally obvious to an attentive reader with a good understanding of C.
- 153 (0) minor technical fixes. These are typically obvious fixes to minor technical errors or imprecisions in the text. In a few cases, they are simply typos or wording errors in a technical detail. (In many cases, these issues probably wouldn't have impacted the reader's understanding of the topic.)
- 102 (0) minor clarifications. These are improvements or fixes to minor details in the text. In many cases, the fix could simply have been omitted (the problem would have been unlikely to trouble most readers), but I took the opportunity anyway to improve the text because it was easily possible to do so.
- 187 (0) typo fixes. Spelling and grammar corrections and fixes to obvious wording errors.
- 78 (-) updates regarding technical details that are new since the book was published. These updates won't be applied to the text of the current edition (but most will appear in the second edition, when it one day appears).
Probably only the first three classes of errata are going to matter to most readers, along with possibly some of the errata in the fourth category—i.e., a small proportion of the errata. (Probably the topics in the "update" category will also be of interest to many readers, but these are simply new pieces of technical information unavailable at the time of publication, rather than errors in the original text.)
By now, I think most of the problems have been found and fixed, so that the number of new errata in each print run is rather small (e.g., 8 fixes in the eighth print run).
I took over maintenance of the Linux man-pages project in 2004. Since that time, I've expanded the remit of Section 7 to include many more pages that give overviews/big pictures of how APIs are related. (I've written many of these pages myself.) So, "man7" for me is about giving the big picture about Linux APIs, and was the inspiration for the domain name.