Slashdot Mirror
Linux System Programming
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.
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.
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.
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.
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.
I to..err... know this poor bastard who took all his compsci courses in C++. How hard would it be for a C++ coder to dig into this book?
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
I like UNIX systems programming when it's complete; even when that surprises me. Recently, for example, I had to find a way to know how many processes had open file descriptors to a certain file. You know, the old shared database thing; so that I can make sure that I'm the only one in at a certain point (inside a file lock), to do some checks an'all. To no avail; UNIX basically said: 'if you can't do it with file locks, don't bother'. Then I discovered the good old sys/ipc.h and the associated sys/sem.h and sys/shm.h. Turns out that my issue *has* been thought about, and in a good way too. Sure, the APIs aren't all 'modern' feeling; lots of things are done with extremely short function-names, ellipsis and setting bits inside special structs, but it works. And it's fast too.
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...
Religion is what happens when nature strikes and groupthink goes wrong.
You can probably tell I can't program, but what is "K&R level of experience" ?
CDE open sourced! https://sourceforge.net/projects/cdesktopenv/
...if the amazon reviews are accurate.
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 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.
"Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
Robert has done plenty of useful work, but it was George AnzigerAnzinger who developed the Linux preemption patch. Robert picked it up, maintained it and got it merged. The credits to George seemed to have gotten lost somewhere in that process.
Credit where credit is due please.
Have you got your LWN subscription yet?
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.
In Soviet Washington the swamp drains you.
Their about page calls it the "perl interpreter" multiple times. How is it not an interpreted language?
Perl is compiled into an AST, goes through code improvements, and then is executed.
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.
oh hai, I ated your lexical parser ._.
which is totally what she said
That's not surprising, since the use of '42' is an artifact of the Ada binding, and those systems do not by default contain an implementation of 1003.5/9945. They should, but that's another story. Ada actually meshes very nicely with Unix, and is a good choice for system-level programming above the kernel level. Strong Typing -is your friend-! (I've been doing library level system programming on Unix systems, starting with Ultrix in 1984...)
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
Still I use perl for my numerical calculations. There is a nice data language for matrix operations: PDL, which might be able to compete with matlab speeds. And my main reason to use perl: the short time needed to get a perl program that can reformat your input data in a nice way is without comparison. The same counts for adapting your program to a changed data format, added variables, etc. String handling and memory handling in C is a big big pain. Currently, I try to solve my problems with perl first, and for anything that is likely to frequently require runtimes longer than a day I rewrite my perl program into C.
molmod.com - computing tips from a molecular modeling
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 programmer will write the same program as the C programmer, but in a fraction of the time. If we are generating fractals or something, the C programmer's version will me smaller and run much faster, but, in the same amount of development time, the Perl programmer can write his program and be out to dinner and a movie. Or trolling Slashdot or whatever.
Is a great kernel developer/programmer (He also does columns for Linux Journal). He is not a general purpose Linux programming author.
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,
It's just the normal noises in here.
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.