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.
What about a C++ coder? (Score:3, Interesting)
Re: (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: (Score:1)
Re:What about a C++ coder? (Score:5, Informative)
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.
For example variable-length arrays (added by C99) are not supported by C++ (which has vector objects instead).
Re:What about a C++ coder? (Score:5, Informative)
C++ is damn close to being a superset of C. Any C code examples given in this book are almost sure to be valid C++. Further, the fact that C code makes for awkward and ugly C++ code doesn't mean that it isn't *valid* C++ code.
C and C++ are very different languages in programming style, but anyone who knows C++ already knows the C syntax and semantics - at most they'll need to learn the modern C programming style to actually use it.
Re:What about a C++ coder? (Score:4, Informative)
C++ was originally a superset of C. But later changes to C / C++ have drifted considerably from that. However, that means that generally C shouldn't be a problem for C++ programmers. There are large differences in the philosophy though that will affect the quality of your C code.
Re: (Score:3, Informative)
int main(void) {
int class = 0;
return 0;
}
was never a valid C++ or Cfront program, but it has always been (and probably will always be) a valid C program.
I'm not an expert on Cfront, but I do know that there are quite a few major differences between C and ARM C++ (sizeof character literals, meaning of empty argument list, type conversions), so your characterization of C++ as having diver
Re: (Score:2)
http://www.research.att.com/~bs/bs_faq.html#C-is-subset [att.com]
Re:What about a C++ coder? (Score:4, Informative)
I didn't say 'recently'. I remember it was stated that C++ WAS a superset. Though it was probably moer accurate to say a superset of ANSI C. In fact there were early C++ compilers that actually preprocessed the C++ code into C first. Of course I am talking 15-20 years ago.
So I stick to my remarks.
Bloody young whippersnappers.
A comment that follows has a link to Stroustrop's page about this. Yes it is not a mathematical superset. But it is practically one:
Re: (Score:2)
For example variable-length arrays (added by C99) are not supported by C++ (which has vector objects instead).
Vector objects are not a replacement for C99 variable length arrays. In the test application I wrote I found them to be quite expensive, to the point where the relatively trivial bookkeeping I had them doing was eating as much time as the (many) syscalls. C99 VLA's on the other hand seem to generate impressively efficient code (gcc, which is traditionally not noted for its great code generator). A rather natural extension involving no new syntax, just allowing a dynamic expression for the array dimensio
Re: (Score:3, Informative)
The current C++ folks are more interested in fixing the mess they made with templates. Designated initializers would be mostly unnecessary if the language supported named argument mapping a la Ada
Re: (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: (Score:2)
http://www.fullduplex.org/humor/2006/10/how-to-shoot-yourself-in-the-foot-in-any-programming-language/ [fullduplex.org]
Re: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:2, Informative)
Having said that, if you have no problems understanding man pages for system calls, you should be good to go.
Re: (Score:2, Insightful)
Re: (Score:2)
for (i = 0; i < 42; i++)
{
cerr >> "know this poor bastard who took all his compsci courses in C++." >> endl;
}
Re: (Score:3, Funny)
You lose too.
See? When you use C++, everyone loses!
Re: (Score:2)
So many errors, so little code...
What I like about it. (Score:5, Interesting)
Now if they only had a good standard API to a versioned, networked filesystem. Then I would be in heaven. But a guy can dream...
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Try ext3cow [ext3cow.com] and NFS.
All accessible from Perl! (Score:1, Informative)
Re:All accessible from Perl! (Score:4, Insightful)
Re: (Score:2)
When was it not? (Score:3, Informative)
Re: (Score:1)
It is not an interpreted language because it's compiled at runtime. Why do you think there isn't an interactive Perl interpreter (at least that I know of)?
It's called an interpreter for the lack of a better name. It's usually used to run a script; I haven't seen it used too often to compile the scripts. The closest I can think of is perlcc.
Re: (Score:2, Informative)
Actually, you can start a debugger session with perl -de 1 (that's the number 1 ; any other empty script will do). That acts like an interactive Perl interpreter would (but really is a loop of "user entry/eval(user entry)/start again").
Still, you're right in that Perl is a compiled-then-interpreted language (like Python and others).
Re: (Score:2, Insightful)
Ultimately all source code has to get translated into machine code to be able to "run" the program. It's just a matter of when this happens (and how often). Once, on the developer's time. Or every time, on *my* fucking time. The former is compiled, the latter is interpreted.
Re: (Score:2)
(I know that's not what you hinted at, but it's an interesting distinction for some purposes - think about access password for your database).
Re:All accessible from Perl! (Score:4, Informative)
Since it typically goes through this every time you use a program from the command line, the startup time tends to be pretty heavy.
If you're using something like mod_perl or FastCGI or some other caching dispatch mechanism, your program gets dispatched without recompilation if it hasn't been changed.
If your program is long-running, then the startup cost can become negligible.
Perl's common routines are written in optimized C and with good algorithmic design in mind. If someone writes an equivalent from scratch in C instead of using a good library, then the Perl version will have been designed and refined by far more people.
It's true that in many cases C comes out well faster than Perl, but those cases are not as common as people tend to think.
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
Any way you could back that up with some numbers?
Unless your program only crunches a lot of numbers during its entire runtime (for example the ImageMagick tools) your program will spend most of its time waiting on some kind of I/O. This encompasses pretty much all software you will find on a normal desktop computer. Perl and C both spend the same amount of time waiting on I/O operations. It comes down to spinning disks or waiting on the slow, clumsy fingers of users.
On the other hand, Perl is faster when it comes to development time. The Perl progra
Re: (Score:2)
Program in C, eh?
Re: (Score:2)
Re: (Score:2)
K&R (Score:5, Interesting)
Re: (Score:3, Informative)
Re: (Score:2)
(In general, the beard-and-suspenders set's insistence upon K&R specifically as an introductory programming text does students a disservice. It's a beloved historical artifact, but it's hardly the best current text for new programmers to start with. I doubt if K&R themselves would argue otherwise.)
Re: (Score:2)
(In general, the beard-and-suspenders set's insistence upon K&R specifically as an introductory programming text does students a disservice. It's a beloved historical artifact, but it's hardly the best current text for new programmers to start with. I doubt if K&R themselves would argue otherwise.)
If you think K&R only exposes you to simple code examples, you haven't really read it.
It's beloved because of its thoroughness despi
Re: (Score:2)
There are certainly better books for first-time programmers, but that's largely because there are better languages for first-time programmers.
As an introduction to the C language, I think the book is a good tool. As an introduction to programming, perhaps SICP, something on ocaml, or something teaching a modern C descendant like D, Objective C, or even C#.
Re: (Score:1)
http://en.wikipedia.org/wiki/K_and_R_C [wikipedia.org]
He probably means he's read the book. It doesn't contain things like systems programming.
It are noted? (Score:2)
Well, I hope it aren't noted using grammar like that.
Re: (Score:3, Funny)
advanced programming in the unix environment? (Score:1)
Re: (Score:2)
The great thing about sticking to Advanced Programming in the Unix Environment for what it covers is that the same guy wrote the networking stuff in those others. He also wrote 3 volumes of TCP/IP Illustrated in case you really want to dig deeply into networking.
If you want t
Looks cool, but I'll wait and see... (Score:3, Interesting)
O'Reilly is great, but I do think you gotta be careful; a lot of their books can, at times, seem to be mostly printouts of man pages (and other freely available documentation), as this reviewer notes:
If you expect the quality of the author's other books from this book, you'll be disappointed. It just lists system calls and their descriptions that you can find from man pages without any serious examples. It doesn't provide any insight or thorough coverage you can find from other books such as Steven's book.
Richard Stevens [wikipedia.org] was definitely "the man" when it came to writing books like this; I'd recommend them to anyone. Anyone who attempts to cover the same ground (even years later) has a tough act to follow.
I've bought a lot of computer books over the years, and for my money, none have been as well-written and valuable as Stevens'.
RIP, Richard.
Re: (Score:1)
Re: (Score:2)
IIRC, someone came with a revised APUE two years ago or so.
But yeah -- there are a few interesting questions. What does this book offer which isn't in Advanced Programming in the UNIX Environment, the man pages and the relevant standards? Is the reviewer familiar with Stevens' work? And why is the revie
Robert didn't develop the preemptive Linux kernel (Score:3, Informative)
Credit where credit is due please.
Re:Robert didn't develop the preemptive Linux kern (Score:1)
Re:Robert didn't develop the preemptive Linux kern (Score:1)
Thou shalt not ignore warnings (Score:5, Informative)
Build your code with -Wall -Werror (or your compiler's equivalent). Once you clean up all the crud, that pops up, crank it up with -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith. Once there — add -Wreturn-type -Wcast-qual -Wswitch -Wshadow -Wcast-align and tighten up by removing the no in -Wno-unused-parameter. The -Wwrite-strings is essential, if you wish your code to be compiled with a C++ compiler some day (hint: the correct type for static strings is " const char *").
For truly clean code, add -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls.
The people, who wrote and maintain the compiler, are, most likely, several levels above you in understanding programming in general and C-programming in particular. Ignoring the advice their code generates is foolish on your part...
As a minimum, solved warnings will make your code more readable by reducing/eliminating the "Why is he doing this?" questions. More often than not, they point out bugs you would otherwise spend hours chasing with a debugger later.
And they make your code more portable. But if you don't understand, why a warning is generated — ask around. Don't just "shut it up". For example, initializing a variable at declaration is usually a no-no. If the compiler thinks, the variable may be used before being initialized, scrutinize your program's flow. If you can't figure out, it may some times be better to disable this one warning temporarily with -Wno-uninitialized to move on, instead of shutting it up for ever by a bogus "= 0" or some such...
The book may well say something about respecting warnings, but the review does not, which is a shame.
Re:Thou shalt not ignore warnings (Score:5, Informative)
That's why, when we did the Ada Binding to POSIX (IEEE 1003.5/ ISO 9945), we decided to accept the overhead of imposing exceptions for system call error returns (in most cases). You can't ignore the exception!
This raised two interesting concerns that we discussed when developing the standard:
1. What about tasking/threads/concurrency? The requirement on the implementation was to set up per-task errno values. From an implementation perspective, this meant that you needed to go outside of the standard interface to correctly implement POSIX/Ada, as you needed to grab the errno value and load it into task-specific storage, or require that your underlying POSIX threads implementation (if that's how you built the Ada runtime) do that for you. In practice, this is not too onerous, and it's proven to be a real boon for ensuring proper behavior (including debugging) in a multithreaded/multitasking environment.
2. We also needed to think about the situation (usually representing really poor programming) where an unhandled exception (from a system call, an application call, or a language predefined exception) rips up the callstack and terminates the process. We wanted a return value from the process exit that would be 'close to 1 but not collide with commonly used values.' The number we chose: 42 (with the appropriate citation in the bibliography:-)
So sure, a C++ program can use the C binding, but I think defining and using C++ exceptions in a better C++ interface would be preferred.
dave (Tech Editor for the original IEEE P1003.5 project...)
Ada's approach to syscall-failures (Score:2)
Dave, this is fascinating, but rather unrelated to my post. I don't know, why you chose to post a follow-up, rather than start a thread of your own.
Interestingly, 42 is not listed in /usr/include/sysexits.h on neither Solaris, nor FreeBSD, nor Linux...
Re:Ada's approach to syscall-failures (Score:4, Informative)
The standard Linux/Solaris Ada compiler is the GNU Ada Compiler, http://www.gnat.com
But at least it's good to know there isn't a conflict.
dave
Re: (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.
Re: (Score:1, Insightful)
Re: (Score:2, Funny)
Re: (Score:2)
Re: (Score:2)
That's what -W is :-)
For more — add the flags by hand. I listed quite a few — borrowed from FreeBSD's BDECFLAGS (collected by Bruce Evans).
Re: (Score:1)
Re: (Score:2)
First of all because it is (slightly) inefficient. Second is because in most cases, the variable will get some other value later on in the function — and you'd like the compiler to tell you, if in some cases it may not get it.
Re: (Score:1)
Re: (Score:1)
And they make your code more portable. But if you don't understand, why a warning is generated — ask around. Don't just "shut it up". For example, initializing a variable at declaration is usually a no-no. If the compiler thinks, the variable may be used before being initialized, scrutinize your program's flow. If you can't figure out, it may some times be better to disable this one warning temporarily with -Wno-uninitialized to move on, instead of shutting it up for ever by a bogus "= 0" or some such...
So, what you are saying is that you'd rather see the program fail with a completely bogus value you have no idea where it is coming from (which is whatever was on the stack at the time the variable was pushed) than a known invalid initialization value (e.g. -1) you pick and you set your variable to ?
This has long debugging session written all over it...
Re: (Score:3, Informative)
This sort of error is easily caught with something like Purify [wikipedia.org] or valgrind [wikipedia.org].
Also, if the warning was generated, you disabled it, and your program failed with a random result, that's a very good indicator, tha
Re: (Score:2)
Re: (Score:1)
Re: (Score:3, Informative)
I always use -W -Wall -pedantic -std=c89 plus any glibc #defines to enable POSIX/BSD/whatever functions I need.
Seeing people respect and use the gcc warning flags makes me happy, but I don't know why you chose to leave out -pedantic and (more importantly!) the option to select which bloody language you are feeding the compiler.
Re: (Score:2)
Wow, not only from someone knowing gnome, which is famous for breaking all of Unix philisophy wherever it meets it (I personaly especially hate glib for ignoring my setting of $HOME), but even from NetworkManager, the tool you use when you want a non-working network configurable by graphic means between not-working, currently non-working and permanently non-working.
Well, I must agree with you there. Perhaps he has good internal knowledge but in my opinion the NetworkManager tool user interface is poorly thought out. What does the check box mean? Why does it change settings repeatedly? Why doesn't network-manager-vpnc not accept my existing conf file? Why is Location blank on my system, I click on the combobox and it changes to the one location that I do have defined and doesn't change back to blank. How can I export settings? Where are the settings stored? Why doesn
Re: (Score:2)
One of my favourite books ever (Score:1, Informative)
As soon as I heard that Robert Love had written this book about userspace programming, I rushed to buy it.
I had really enjoyed both "Linux Kernel Development" (Developer's Library, 2003) and "Linux Kernel Development 2nd ed." (Novell, 2005). I like how clearly and brightly the author describes linux internals, from the major architectural components to the key code chunks.
This book was a great surprise. It's the best you may desire when you have to quickly design and develop complex solutions with glib
Robert Love .... (Score:3, Informative)
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.
For getting your feet wet with Linux programming I recommend GNU/LINUX Application Programming by M. Tim Jones or Linux Application Development by Michael K. Johnson and Erik W. Troan.
The Linux Unleashed series is also good (1000+ pages with hundreds dedicated to perl, python, and Gtk programming).
Enjoy,
Not for C beginners (Score:1)
Re: (Score:1)
Re: (Score:1)
Tour de France Riding. (Score:2)