Linux System Programming 98
Jon Mitchell writes "As a Perl programmer recently thrown in to the world of C development on
Linux, I have been looking for something that would take my K&R level of
experience and bring it up to date with modern methods, hopefully
letting me write more efficient and reliable programs.
Linux System Programming is a volume that targets this need. Robert Love, former "Chief Architect, Linux Desktop" at Novell, kernel
hacker of many years, and Gnome developer of well known features such as Beagle
and NetworkManager, attempts in this book to document the Linux system call
and C API to common systems programming tasks. Given that he developed
the pre-emptive kernel and inotify he has the knowledge." Read below for the rest of Jon's review.
Getting this book out of the box, I had wrongly been expecting a cookbook
style that I would get instant gratification from. Although structured
around common programming tasks, it doesn't lend itself to just dipping in.
The section on time lists a handful of ways that "time" is available to the
programmer; jump into the middle of the section and you might miss
the most suitable one for the job in hand. The book rewards reading it
in larger chunks.
| Linux System Programming | |
| author | Robert Love |
| pages | 388 |
| publisher | O'Reilly Media |
| rating | 8/10 |
| reviewer | Jon Mitchell |
| ISBN | 9780596009588 |
| summary | The Linux system call and C API explored in depth. |
This doesn't mean it is necessary to read it from cover to cover. Logically organized into chapters around "things you want to do", such as file access, memory management and process management it will lead you in with a survey of techniques you might be familiar with, before drilling down with advanced methods.
Knowing advanced methods for performance is great, but not at all costs. One of the most useful and practical lessons this book gives is to encourage you to think about error conditions that may occur during a system call. Early on, in the section on reading files, a detailed example is given on reading from a file. Every possible case of return code from the read call is described together with what it means and how you should handle it — it can be surprising that 7 possible outcomes are listed, with good descriptions of what to do with each of them.
This good practice by example continues throughout the book. Every system call described also lists the errors that may occur. This does show up a slight weakness: many system calls share a common set of errors which are repeated many times in the text. If you are not paying attention it may feel like you are just flipping through man pages. However you are soon halted by the easy introduction of an advanced concept to get your teeth into.
These are done in a nicely graded level for each topic. In "file access" to give an example, you are lead from simple read/write calls, through to what the C library can provide in buffering, to improved performance using mmap. The techniques continue with descriptions of I/O schedulers and how the kernel will order hardware disk access, scatter/gather, and ends up with how it is possible to order block reads/writes yourself bypassing any scheduler.
You are hardly aware of the progression, as the pacing is very well done. New concepts clearly fit into what you have seen so far — current sections signpost the practical use of what is being explained and at what cost, allowing clear consideration of the use of advanced features against any consequences.
For process management discussion starts with fork and exec, before moving onto user ids and groups, covers daemonification and goes onto process scheduling, including real time scheduling. Throughout the book each new call is illustrated with a short code snippet showing the call being used in a practical situation.
Not everything is present and correct. The author immediately states that networking is not covered at all. This is a shame as this subject would benefit from the depth of coverage given to the topics in this book — although no doubt would increase the number of pages considerably. Perhaps scope for a second volume. The length of some sections seems odd — Asynchronous file I/O is whizzed through in a page with no code example, whereas I/O schedulers gets a luxurious 12.
On the other hand there are some unexpected and useful extras, such as a discussion in the appendix of gcc C language extensions and how they might be used to fine tune your code.
The books stated target is for modern Linux development, a 2.6.22 kernel, gcc 4.2 and glibc 2.5. Many calls have been standardized by POSIX, and where this is so it are noted in the text, so a large portion of the content is useful on other systems. There is even the occasional mention of non-Linux system calls, the use of which is not encouraged, but shown so you know how they function if you come across them in older code.
I recommend this book to anyone who has a need to developing Linux applications. The book is not a primer in C on Unix, so you are expected to be familiar at least to the level of K&R. From this level though the journey into getting the best from the kernel and C library into your programs is easy going and enjoyable.
You can purchase Linux System Programming from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:What about a C++ coder? (Score:2, Funny)
Re:What about a C++ coder? (Score:5, Funny)
Should be pretty easy. All the code examples are valid C++. All you need to do is remember that "class" is called "struct" and that you have to mangle your own names.
Re:What I like about it. (Score:3, Funny)
Re:What about a C++ coder? (Score:3, Funny)
Should be pretty easy. All the code examples are valid C++. All you need to do is remember that "class" is called "struct" and that you have to mangle your own names.
Re:It are noted? (Score:3, Funny)
Re:What about a C++ coder? (Score:3, Funny)
You lose too.
See? When you use C++, everyone loses!
Re:Thou shalt not ignore warnings (Score:2, Funny)
Re:Ada's approach to syscall-failures (Score:3, Funny)
Well of course you wouldn't want to *list* 42 as a possible exit code. If you did that, we'd be continually getting our Ada programs interrupted by Vogon destructor fleets.