The Linux Programming Interface: A Linux and UNIX System Programming Handbook

Author: Michael Kerrisk
All Stack Overflow 10
This Year Hacker News 2
This Month Hacker News 1


by anonymous   2017-12-11
I suggest any of these 3 books (1 is enough to start with; you can get the others later): W Richard Stevens, Stephen A Rago [Advanced Programming in the Unix Environment, 3rd Edn]( — Marc J Rochkind [Advanced Unix Programming, 2nd Edn]( — Michael Kerrisk [The Linux Programming Interface: A Linux and Unix System Programming Handbook](
by nlg   2017-08-20
I've really enjoyed the book The Linux Programming Interface by Kerrisk as a guide for learning some of these types of low level concepts.

by anonymous   2017-08-20

I discovered this too for anyone interested. Apparently it is the "New standard" for linux programming. alt text

The Linux Programming Interface: A Linux and UNIX System Programming Handbook

by anonymous   2017-08-20

OK, this is what I did. Disclaimer: I'm a hacker in the pure sense of the word and my code ain't the prettiest. I read LDD3 and infiniband source code and other predecessor stuff and decided that "get_user_pages" and pinning them and all that other rigmarole was just too painful to contemplate while hungover. Also, I was working with the other person across the PCIe bus and I was also responsible in "designing" the user space application. I wrote the driver such that at load time, it preallocates as many buffers as it can with the largest size by calling the function myAddr[i] = pci_alloc_consistent(blah,size,&pci_addr[i]) until it fails. (failure -> myAddr[i] is NULL I think, I forget). I was able to allocate around 2.5GB of buffers, each 4MiB in size in my meagre machine which only has 4GiB of memory. The total number of buffers varies depending on when the kernel module is loaded of course. Load the driver at boot time and the most buffers are allocated. Each individual buffer's size maxed out at 4MiB in my system. Not sure why. I catted /proc/buddyinfo to make sure I wasn't doing anything stupid which is of course my usual starting pattern. The driver then proceeds to give the array of pci_addr to the PCIe device along with their sizes. The driver then just sits there waiting for the interrupt storm to begin. Meanwhile in userspace, the application opens the driver, queries the number of allocated buffers(n) and their sizes (using ioctls or reads etc) and then proceeds to call the system call mmap() multiple (n) times. Of course mmap() must be properly implemented in the driver and LDD3 pages 422-423 were handy. Userspace now has n pointers to n areas of driver memory. As the driver is interrupted by the PCIe device, it's told which buffers are "full" or "available" to be sucked dry. The application in turn is pending on a read() or ioctl() to be told which buffers are full of useful data. The tricky part was to manage the userspace to kernel space synchronization such that buffers which are being DMA's into by the PCIe are not also being modified by userspace but that's what we get paid for. I hope this makes sense and I'd be more than happy to be told I'm an idiot but please tell me why. I recommend this book as well by the way: . I wish I had that book seven years ago when I wrote my first Linux driver. There is another type of trickery possible by adding even more memory and not letting the kernel use it and mmapping on both sides of the userspace/kernelspace divide but the PCI device must also support higher than 32-bit DMA addressing. I haven't tried but I wouldn't be surprised if I'll eventually be forced to.

by anonymous   2017-08-20

The Linux Programming Interface is amazing book I am reading now:

Just look at its outstanding customers range - it is really excellent Linux programming book.

by techjuice   2017-08-19
If you want to become a professional and not just a dabbler I would recommend reading some of the following books I have in my bookshelf:

[0] RHCSA & RHCE Training and Exam Preparation Guide by Asghar Ghori. This book will help insure you know your stuff as your system engineer/administrator wise.

[1] A Practical Guide to Linux Commands, Editor and Shell Programming Third Edition. This book will cover the majority of what you would need and want to know when connecting to a remote linux system over ssh.

If you want to get under the hood and become an expert, the following books should help get you started:

[2] Advanced Programming in the UNIX Environment

[3] The Linux Programming Interface: A Linux and UNIX System Programming Handbook

[4] Linux Kernel Development 3rd Edition

To get a nice general overview and get up and going quickly:

[5] How Linux works: What every superuser should know

[6] The Linux Command Line

[7] Python Crash Course

[8] Automate the boring stuff with Python. This is a great book to help you think about how to automate most of the repetitive things you will end up doing on a regular basis.










by robomartin   2017-08-19
OK, if you don't have any real experience in low-level embedded coding (relevant to device drivers), RTOS or OS design in general, file systems, data structures, algorithms, interfaces, etc. And, if you have "hobby level" experience with Assembler, C and C++. And, if your intent is to write a desktop OS, from the ground up, without making use of existing technologies, drivers, file systems, memory management, POSIX, etc. Here's a list of books that could be considered required reading before you can really start to write specifications and code. Pick twenty of these and that might be a good start.

In no particular order:






















































54- ...well, I'll stop here.

Of course, the equivalent knowledge can be obtained by trial-and-error, which would take longer and might result in costly errors and imperfect design. The greater danger here is that a sole developer, without the feedback and interaction of even a small group of capable and experienced programmers could simply burn a lot of time repeating the mistakes made by those who have already trenched that territory.

If the goal is to write a small RTOS on a small but nicely-featured microcontroller, then the C books and the uC/OS book might be a good shove in the right direction. Things start getting complicated if you need to write such things as a full USB stack, PCIe subsystem, graphics drivers, etc.

by skb_   2017-08-19
The Linux Programming Interface by Kerrisk has pretty thorough coverage of sockets (and everything else).

by joshbaptiste   2017-08-19
The Linux Programming Interface: A Linux and UNIX System Programming Handbook