The following is a list of frequently asked questions and answers related to the The Linux Programming Interface.
Sorry, but no. 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 benefit 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.
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.
As a general principle, existing Linux kernel-userspace 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-userspace 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 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-userspace 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. For various chapters, I worked quite hard at the task, and TLPI contains what I managed to produce. Perhaps with even more effort, I would have found more good 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.
Assuming that 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 userspace 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 here.) In summary, it's not clear that the current (Linux) POSIX AIO interface is widely used.
For these general and specific reasons, beyond a mention on page 1327, I didn't describe POSIX AIO. 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 this link.
There are many conventions for identifiers in C, with underscore-separators (a common and early convention, and the one used in the kernel-userspace 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: 1500 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 384 errata documented as at 12 March 2012 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):
- 8 (1) fixes to significant code problems.
- 1 (0) significant fix to an explanation in the text.
- 6 (1) significant fixes to technical details explained in the text.
- 24 (3) 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.
- 89 (27) minor technical fixes. These are typically obvious fixes to minor technical errors or imprecisions in the text. (In many cases, these issues probably wouldn't have impacted the reader's understanding of the topic.)
- 83 (16) 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.
- 137 (60) typo fixes. Spelling and grammar corrections and fixes to obvious wording errors.
- 36 (-) 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, which will be some years away).
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.)This FAQ typically comes from someone wondering "should I wait for the next print run of the book, so that I get a copy with all of the errata applied?". My answer is "no", because, as described above, only a few of the errata are likely to matter. There are also other reasons not to worry too much about print runs: generally there are at least several months between print runs, and even after a new print run is completed you can't predict with certainty which print run of the book you'll receive from a bookseller.
(C) 2013 Michael Kerrisk, mtk AT man7.org