1   2   3   4   5   6   7   8

Is This a Good Book for Linux Programming?

From Chris Gianakopoulos

Answered By John Karns, Faber Fedor

Hello Gang, I've mentioned that I am working on an embedded project that will use Linux as its kernel. As a result, I am learning to write cool software for the Linux platform.

The type of stuff that I have to do will be fork()s and exec()s (the "s" indicates lots of fork() and exec() invocations), IPC stuff, signals (I know -- that's IPC stuff, too). and pipes. I know that there will be slight differences (for example, the spawn() function), but now for the question.

There are lots of good guides (and of course, the man pages). I am also presently reading a book entitled "Advanced Programming in the Unix Environment" by Stevens.

Will that Stevens book lead me astray? It really is giving me lots of good insight (what other insight could there be?), so I hope that you tell me that it is good reading for learning to create complex software systems in Linux.

Of course, I will read the man pages and guides, and I expect that some header file may be in different places (I saw slight differences for network programming).

[J.Karns] I've seen that book recommended for Linux programming on a LUG list I subscribe to. Additionally, this one:

The Design of the Unix Operating System, Pr. Hall, ISBN-0-13-201799-7 Moris J. Bach

Thanks for the confirmation. I've got the Bach book and read it years ago. It is my reference for Unix internals. I will read the Stevens book just for the sport of it since it applies to my FreeBSD system. I am happy that it also applies to Linux.

[Faber] Excellent book, IMO. I was re-reading it Friday night (yes, I need a life and still learning new things.

I claim to have a life -- my peers don't agree with me when I start to talk about technical stuff. I'm almost finished with chapter 9 -- the stuff that talks about session leaders and stuff. Soon I read about signals -- almost like writing interrupt handlers only a little easier.

[Faber] I don't do the kind of programming that you do, but I think the combination of the Stevens book and the kernel documentation (usr/src/linux/Documentation assuming you've installed the kernel sources) should do you well

It will be not quite like an embedded project. That's what makes it fun because it will be more like standard Unix programming (which I have not yet done). I'll have to deal with such issues as do I run various servers as daemons? What if I want daemon-to-daemon communication -- do I use named pipes?

As I learn and discover, I will pass this type of information as 2 cent tips.

Thanks for that info, Fabor. I will keep that Linux Documentation stuff in my mind. I know that I ramble whenever I talk about this project that I am working on. Here's why, though.

When I was doing DSP (digital signal processor) programming, I would ask myself questions like "I wish that I could use DMA for those A/D samples." Then, I would turn around and discover that the feature existed.

Linux is the same way. I'm architecting this system as I were designing hardware to do the job. You want I/O? Use the messaging IPC. That allows programming language independence with respect to server implementation. Linux (and Unix) has all of these cool things that provide for a concurrent implementation of the system.

And that stability. The things that people can do when they work together!!

This page edited and maintained by the Editors of Linux Gazette Copyright © 2001
Published in issue 71 of Linux Gazette October 2001

HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/

1   2   3   4   5   6   7   8