Linux Kernel Development (3rd Edition)

It amazes me sometimes how much of a dying breed systems engineers are. When I was coming up as a SWE I worked for a series of systems engineers, so I learned software from a systems engineering perspective and it's been invaluable as distributed systems have gotten bigger and more OS-like.

If you're wanting to dive a little deeper than this guide touches check out:

- https://www.amazon.com/Linux-Kernel-Development-Robert-Love/... - Really good for understanding why Linux is the way it is. The Kernel this book was written on is awful old, but the principles shine through.

I read this book few years ago:

Linux Kernel Development by Robert Love. It was not too hard read for newbie like me. I was just dabbling in understanding few things about OS in general.

https://www.amazon.com/Linux-Kernel-Development-Robert-Love/... https://rlove.org/

any process?
if you don't manually put a limit there, any process can take 100% of your memory. when it runs out of memory the OOM Killer will go on a spree.
I read about these stuff in: http://www.amazon.com/Linux-Kernel-Development-3rd-Edition/dp/0672329468

For the conceptual part, you can read Robert Love's Linux Kernel Development. The book generally says you can use functions like

struct task_struct * kthread_create (...);

struct task_struct * kthread_run (...);

struct task_struct * kthread_stop (...);

to manage threads. Threads are actually light-weight processes in the kernel. So you would need to do your homework on processes as well, if you haven't done so.

For the consumer-producer problem, here's an example using pthread.

Hope this helps.

I don't think there's a one-stop shop for your question. Your best option here is to read ALL the kernel documentation. There's not much else you can do - concurrency is just fundamental to the kernel, almost every part of the kernel needs to be aware that it may be running at the same time as other parts. In that vein, the simple answer is that all of the kernel is implemented as multi-threaded - although highly-concurrent would probably be a better term because the concept of a 'thread' is also implemented by the kernel and kernel concurrency is not necessarily thread-based. Every individual driver needs to be aware that parts of it can be executing concurrently, so they all have to use the internal synchronisation techniques to ensure the safety of shared data.

https://www.kernel.org/doc/Documentation/

You'll also find subsystem specific stuff on various websites and in various books, although they'll also be variously out of date...

• http://ptgmedia.pearsoncmg.com/images/0131453483/downloads/gorman_book.pdf
• http://www.amazon.co.uk/Linux-Kernel-Development-Developers-Library/dp/0672329468/
• http://www.amazon.co.uk/Understanding-Linux-Kernel-Daniel-Bovet-ebook/dp/B0043D2E54
• https://lwn.net/Articles
• http://whatisthekernel.blogspot.co.uk/
• http://linuxburps.blogspot.co.uk/2013/09/linux-kernel-synchronization-primitives.html
• http://www.linux-mag.com/id/2195/
• http://www.linux-mag.com/id/2316/

**TODO** +editPic: Linux Kernel Developer -> (Ring Layer 0)
         +addSection: Kernel Virtualization Engine

KERN_WARN_CODING_STYLE: Do not Loop unless you absolutely have to.

Recommended Books for the Uninitialized void *i

"Men do not understand books until they have a certain amount of life, or at any rate no man understands a deep book, until he has seen and lived at least part of its contents". –Ezra Pound

A journey of a thousand code-miles must begin with a single step. If you are in confusion about which of the following books to start with, don't worry, pick any one of your choice. Not all those who wander are lost. As all roads ultimately connect to highway, you will explore new things in your kernel journey as the pages progress without meeting any dead ends, and ultimately connect to the code-set. Read with alert mind and remember: Code is not Literature.

What is left is not a thing or an emotion or an image or a mental picture or a memory or even an idea. It is a function. A process of some sort. An aspect of Life that could be described as a function of something "larger". And therefore, it appears that it is not really "separate" from that something else. Like the function of a knife - cutting something - is not, in fact, separate from the knife itself. The function may or may not be in use at the moment, but it is potentially NEVER separate.

Solovay Strassen Derandomized Algorithm for Primality Test:

Read not to contradict and confute; nor to believe and take for granted; nor to find talk and discourse; but to weigh and consider. Some books are to be tasted, others to be swallowed, and some few to be chewed and digested: that is, some books are to be read only in parts, others to be read, but not curiously, and some few to be read wholly, and with diligence and attention.

static void tasklet_hi_action(struct softirq_action *a)
{
        struct tasklet_struct *list;

        local_irq_disable();
        list = __this_cpu_read(tasklet_hi_vec.head);
        __this_cpu_write(tasklet_hi_vec.head, NULL);
        __this_cpu_write(tasklet_hi_vec.tail, this_cpu_ptr(&tasklet_hi_vec.head));
        local_irq_enable();

        while (list) {
                struct tasklet_struct *t = list;

                list = list->next;

                if (tasklet_trylock(t)) {
                        if (!atomic_read(&t->count)) {
                                if (!test_and_clear_bit(TASKLET_STATE_SCHED,
                                                        &t->state))
                                        BUG();
                                t->func(t->data);
                                tasklet_unlock(t);
                                continue;
                        }
                        tasklet_unlock(t);
                }

                local_irq_disable();
                t->next = NULL;
                *__this_cpu_read(tasklet_hi_vec.tail) = t;
                __this_cpu_write(tasklet_hi_vec.tail, &(t->next));
                __raise_softirq_irqoff(HI_SOFTIRQ);
                local_irq_enable();
        }
}

---

Core Linux ( 5 -> 1 -> 3 -> 2 -> 7 -> 4 -> 6 )

“Nature has neither kernel nor shell; she is everything at once” -- Johann Wolfgang von Goethe

Reader should be well versed with operating system concepts; a fair understanding of long running processes and its differences with processes with short bursts of execution; fault tolerance while meeting soft and hard real time constraints. While reading, it's important to understand and n/ack the design choices made by the linux kernel source in the core subsystems.

Threads [and] signals [are] a platform-dependent trail of misery, despair, horror and madness (~Anthony Baxte). That being said you should be a self-evaluating C expert, before diving into the kernel. You should also have good experience with Linked Lists, Stacks, Queues, Red Blacks Trees, Hash Functions, et al.

volatile int i;
int main(void)
{
    int c;
    for (i=0; i<3; i++) {
        c = i&&&i;
        printf("%d\n", c);    /* find c */
    }
    return 0;
}

The beauty and art of the Linux Kernel source lies in the deliberate code obfuscation used along. This is often necessitated as to convey the computational meaning involving two or more operations in a clean and elegant way. This is especially true when writing code for multi-core architecture.

Video Lectures on Real-Time Systems, Task Scheduling, Memory Compression, Memory Barriers, SMP

#ifdef __compiler_offsetof
#define offsetof(TYPE,MEMBER) __compiler_offsetof(TYPE,MEMBER)
#else
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
#endif

1. Linux Kernel Development - Robert Love
2. Understanding the Linux Kernel - Daniel P. Bovet, Marco Cesati
3. The Art of Linux KerneL Design - Yang Lixiang
4. Professional Linux Kernel Architecture - Wolfgang Mauerer
5. Design of the UNIX Operating System - Maurice J. Bach
6. Understanding the Linux Virtual Memory Manager - Mel Gorman
7. Linux Kernel Internals - Tigran Aivazian
8. Embedded Linux Primer - Christopher Hallinan

---

Linux Device Drivers ( 1 -> 2 -> 4 -> 3 -> 8 -> ... )

"Music does not carry you along. You have to carry it along strictly by your ability to really just focus on that little small kernel of emotion or story". -- Debbie Harry

Your task is basically to establish a high speed communication interface between the hardware device and the software kernel. You should read the hardware reference datasheet/manual to understand the behavior of the device and it's control and data states and provided physical channels. Knowledge of Assembly for your particular architecture and a fair knowledge of VLSI Hardware Description Languages like VHDL or Verilog will help you in the long run.

• Intel® 64 and IA-32 Architectures Software Developer’s Manual
• ARM Architecture Reference Manual
• ARM System Developer's Guide

Q: But, why do I have to read the hardware specs?

A: Because, "There is a chasm of carbon and silicon the software can't bridge" - Rahul Sonnad

However, the above doesn't poses a problem for Computational Algorithms (Driver code - bottom-half processing), as it can be fully simulated on a Universal Turing Machine. If the computed result holds true in the mathematical domain, it's a certainty that it is also true in the physical domain.

Video Lectures on Linux Device Drivers (Lec. 17 & 18), Anatomy of an Embedded KMS Driver, Pin Control and GPIO Update, Common Clock Framework, Write a Real Linux Driver - Greg KH

static irqreturn_t phy_interrupt(int irq, void *phy_dat)
{
         struct phy_device *phydev = phy_dat;

         if (PHY_HALTED == phydev->state)
                 return IRQ_NONE;                /* It can't be ours.  */

         /* The MDIO bus is not allowed to be written in interrupt
          * context, so we need to disable the irq here.  A work
          * queue will write the PHY to disable and clear the
          * interrupt, and then reenable the irq line.
          */
         disable_irq_nosync(irq);
         atomic_inc(&phydev->irq_disable);

         queue_work(system_power_efficient_wq, &phydev->phy_queue);

         return IRQ_HANDLED;
}

1. Linux Device Drivers - Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman
2. Essential Linux Device Drivers - Sreekrishnan Venkateswaran
3. Writing Linux Device Drivers - Jerry Cooperstein
4. The Linux Kernel Module Programming Guide - Peter Jay Salzman, Michael Burian, Ori Pomerantz
5. Linux PCMCIA Programmer's Guide - David Hinds
6. Linux SCSI Programming Howto - Heiko Eibfeldt
7. Serial Programming Guide for POSIX Operating Systems - Michael R. Sweet
8. Linux Graphics Drivers: an Introduction - Stéphane Marchesin
9. Programming Guide for Linux USB Device Drivers - Detlef Fliegl
10. The Linux Kernel Device Model - Patrick Mochel

---

Kernel Networking ( 1 -> 2 -> 3 -> ... )

“Call it a clan, call it a network, call it a tribe, call it a family: Whatever you call it, whoever you are, you need one.” - Jane Howard

Understanding a packet walk-through in the kernel is a key to understanding kernel networking. Understanding it is a must if we want to understand Netfilter or IPSec internals, and more. The two most important structures of linux kernel network layer are: struct sk_buff and struct net_device

static inline int sk_hashed(const struct sock *sk)
{
        return !sk_unhashed(sk);
} 

1. Understanding Linux Network Internals - Christian Benvenuti
2. Linux Kernel Networking: Implementation and Theory - Rami Rosen
3. UNIX Network Programming - W. Richard Stevens
4. The Definitive Guide to Linux Network Programming - Keir Davis, John W. Turner, Nathan Yocom
5. The Linux TCP/IP Stack: Networking for Embedded Systems - Thomas F. Herbert
6. Linux Socket Programming by Example - Warren W. Gay
7. Linux Advanced Routing & Traffic Control HOWTO - Bert Hubert

---

Kernel Debugging ( 1 -> 4 -> 9 -> ... )

Unless in communicating with it one says exactly what one means, trouble is bound to result. ~Alan Turing, about computers

Brian W. Kernighan, in the paper Unix for Beginners (1979) said, "The most effective debugging tool is still careful thought, coupled with judiciously placed print statements". Knowing what to collect will help you to get the right data quickly for a fast diagnosis. The great computer scientist Edsger Dijkstra once said that testing can demonstrate the presence of bugs but not their absence. Good investigation practices should balance the need to solve problems quickly, the need to build your skills, and the effective use of subject matter experts.

There are times when you hit rock-bottom, nothing seems to work and you run out of all your options. Its then that the real debugging begins. A bug may provide the break you need to disengage from a fixation on the ineffective solution.

Video Lectures on Kernel Debug and Profiling, Core Dump Analysis, Multicore Debugging with GDB, Controlling Multi-Core Race Conditions, Debugging Electronics

/* Buggy Code -- Stack frame problem
 * If you require information, do not free memory containing the information
 */
char *initialize() {
  char string[80];
  char* ptr = string;
  return ptr;
}

int main() {
  char *myval = initialize();
  do_something_with(myval);
}
/*  “When debugging, novices insert corrective code; experts remove defective code.”
 *     – Richard Pattis
#if DEBUG
 printk("The above can be considered as Development and Review in Industrial Practises");
#endif
 */

1. Linux Debugging and Performance Tuning - Steve Best
2. Linux Applications Debugging Techniques - Aurelian Melinte
3. Debugging with GDB: The GNU Source-Level Debugger - Roland H. Pesch
4. Debugging Embedded Linux - Christopher Hallinan
5. The Art of Debugging with GDB, DDD, and Eclipse - Norman S. Matloff
6. Why Programs Fail: A Guide to Systematic Debugging - Andreas Zeller
7. Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code - Bill Blunden
8. Debugging: Finding most Elusive Software and Hardware Problems - David J. Agans
9. Debugging by Thinking: A Multidisciplinary Approach - Robert Charles Metzger
10. Find the Bug: A Book of Incorrect Programs - Adam Barr

---

File Systems ( 1 -> 2 -> 6 -> ... )

"I wanted to have virtual memory, at least as it's coupled with file systems". -- Ken Thompson

On a UNIX system, everything is a file; if something is not a file, it is a process, except for named pipes and sockets. In a file system, a file is represented by an inode, a kind of serial number containing information about the actual data that makes up the file. The Linux Virtual File System VFS caches information in memory from each file system as it is mounted and used. A lot of care must be taken to update the file system correctly as data within these caches is modified as files and directories are created, written to and deleted. The most important of these caches is the Buffer Cache, which is integrated into the way that the individual file systems access their underlying block storage devices.

Video Lectures on Storage Systems, Flash Friendly File System

long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)
{
        struct open_flags op;
        int fd = build_open_flags(flags, mode, &op);
        struct filename *tmp;

        if (fd)
                return fd;

        tmp = getname(filename);
        if (IS_ERR(tmp))
                return PTR_ERR(tmp);

        fd = get_unused_fd_flags(flags);
        if (fd >= 0) {
                struct file *f = do_filp_open(dfd, tmp, &op);
                if (IS_ERR(f)) {
                        put_unused_fd(fd);
                        fd = PTR_ERR(f);
                } else {
                        fsnotify_open(f);
                        fd_install(fd, f);
                }
        }
        putname(tmp);
        return fd;
}

SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode)
{
        if (force_o_largefile())
                flags |= O_LARGEFILE;

        return do_sys_open(AT_FDCWD, filename, flags, mode);
}

1. Linux File Systems - Moshe Bar
2. Linux Filesystems - William Von Hagen
3. UNIX Filesystems: Evolution, Design, and Implementation - Steve D. Pate
4. Practical File System Design - Dominic Giampaolo
5. File System Forensic Analysis - Brian Carrier
6. Linux Filesystem Hierarchy - Binh Nguyen
7. BTRFS: The Linux B-tree Filesystem - Ohad Rodeh
8. StegFS: A Steganographic File System for Linux - Andrew D. McDonald, Markus G. Kuhn

---

Security ( 1 -> 2 -> 8 -> 4 -> 3 -> ... )

"UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things". — Doug Gwyn

No technique works if it isn't used. Ethics change with technology.

"F × S = k" the product of freedom and security is a constant. - Niven's Laws

Cryptography forms the basis of trust online. Hacking is exploiting security controls either in a technical, physical or a human-based element. Protecting the kernel from other running programs is a first step toward a secure and stable system, but this is obviously not enough: some degree of protection must exist between different user-land applications as well. Exploits can target local or remote services.

“You can't hack your destiny, brute force...you need a back door, a side channel into Life." ― Clyde Dsouza

Computers do not solve problems, they execute solutions. Behind every non-deterministic algorithmic code, there is a determined mind. -- /var/log/dmesg

Video Lectures on Cryptography and Network Security, Namespaces for Security, Protection Against Remote Attacks, Secure Embedded Linux

env x='() { :;}; echo vulnerable' bash -c "echo this is a test for Shellsock"

1. Hacking: The Art of Exploitation - Jon Erickson
2. The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System - Bill Blunden
3. Hacking Exposed: Network Security Secrets - Stuart McClure, Joel Scambray, George Kurtz
4. A Guide to Kernel Exploitation: Attacking the Core - Enrico Perla, Massimiliano Oldani
5. The Art of Memory Forensics - Michael Hale Ligh, Andrew Case, Jamie Levy, AAron Walters
6. Practical Reverse Engineering - Bruce Dang, Alexandre Gazet, Elias Bachaalany
7. Practical Malware Analysis - Michael Sikorski, Andrew Honig
8. Maximum Linux Security: A Hacker's Guide to Protecting Your Linux Server - Anonymous
9. Linux Security - Craig Hunt
10. Real World Linux Security - Bob Toxen

---

Kernel Source ( 0.11 -> 2.4 -> 2.6 -> 3.18 )

"Like wine, the mastery of kernel programming matures with time. But, unlike wine, it gets sweeter in the process". --Lawrence Mucheka

You might not think that programmers are artists, but programming is an extremely creative profession. It's logic-based creativity. Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter. As you already know, there is a difference between knowing the path and walking the path; it is of utmost importance to roll up your sleeves and get your hands dirty with kernel source code. Finally, with your thus gained kernel knowledge, wherever you go, you will shine.

Immature coders imitate; mature coders steal; bad coders deface what they take, and good coders make it into something better, or at least something different. The good coder welds his theft into a whole of feeling which is unique, utterly different from that from which it was torn.

Video Lectures on Kernel Recipes

linux-0.11
├── boot
│   ├── bootsect.s      head.s      setup.s
├── fs
│   ├── bitmap.c    block_dev.c buffer.c        char_dev.c  exec.c
│   ├── fcntl.c     file_dev.c  file_table.c    inode.c     ioctl.c
│   ├── namei.c     open.c      pipe.c          read_write.c
│   ├── stat.c      super.c     truncate.c
├── include
│   ├── a.out.h     const.h     ctype.h     errno.h     fcntl.h
│   ├── signal.h    stdarg.h    stddef.h    string.h    termios.h
│   ├── time.h      unistd.h    utime.h
│   ├── asm
│   │   ├── io.h    memory.h    segment.h   system.h
│   ├── linux
│   │   ├── config.h    fdreg.h fs.h    hdreg.h     head.h
│   │   ├── kernel.h    mm.h    sched.h sys.h       tty.h
│   ├── sys
│   │   ├── stat.h      times.h types.h utsname.h   wait.h
├── init
│   └── main.c
├── kernel
│   ├── asm.s       exit.c      fork.c      mktime.c    panic.c
│   ├── printk.c    sched.c     signal.c    sys.c       system_calls.s
│   ├── traps.c     vsprintf.c
│   ├── blk_drv
│   │   ├── blk.h   floppy.c    hd.c    ll_rw_blk.c     ramdisk.c
│   ├── chr_drv
│   │   ├── console.c   keyboard.S  rs_io.s
│   │   ├── serial.c    tty_io.c    tty_ioctl.c
│   ├── math
│   │   ├── math_emulate.c
├── lib
│   ├── close.c  ctype.c  dup.c     errno.c  execve.c  _exit.c
│   ├── malloc.c open.c   setsid.c  string.c wait.c    write.c
├── Makefile
├── mm
│   ├── memory.c page.s
└── tools
    └── build.c

1. Beginner's start with Linux 0.11 source (less than 20,000 lines of source code). After 20 years of development, compared with Linux 0.11, Linux has become very huge, complex, and difficult to learn. But the design concept and main structure have no fundamental changes. Learning Linux 0.11 still has important practical significance.
2. Mandatory Reading for Kernel Hackers => Linux_source_dir/Documentation/*
3. You should be subscribed and active on at-least one kernel mailing list. Start with kernel newbies.
4. You do not need to read the full source code. Once you are familiar with the kernel API's and its usage, directly start with the source code of the sub-system you are interested in. You can also start with writing your own plug-n-play modules to experiment with the kernel.
5. Device Driver writers would benefit by having their own dedicated hardware. Start with Raspberry Pi.

Speaking of the Linux kernel related books, I'd probably mention, Understanding The Linux Kernel [0] and Linux Kernel Development [1]. The LDDv4 is not going to happen any time soon; it seems there are no plans for a new edition at all.

  [0] https://www.amazon.com/Understanding-Linux-Kernel-Third-Daniel/dp/0596005652
  [1] https://www.amazon.com/Linux-Kernel-Development-Robert-Love/dp/0672329468

-ss

I'm new to the development of linux kernel device drivers. I searched online books or courses and every time the courses are up to 2.6 kernel version. Why there are no guide for the newest kernel version (4.x)?

Examples:

• https://www.amazon.com/Linux-Kernel-Development-Robert-Love/dp/0672329468/ref=as_li_ss_tl?ie=UTF8&tag=roblov-20
• https://lwn.net/Kernel/LDD3/
• https://www.tldp.org/LDP/lkmpg/2.6/lkmpg.pdf
• https://www.apriorit.com/dev-blog/195-simple-driver-for-linux-os

In this response Linux kernel books for 3.x someone reply that there are no particular difference between 2.6 and 3.x, is this reply still valid for version 4?

sure, in my opinion these 3 books are essential, ["Linux Kernel Development", Robert Love](https://www.amazon.com/Linux-Kernel-Development-Robert-Love/dp/0672329468), ["Linux Device Drivers", Jonathan Corbet](https://www.amazon.com/Linux-Device-Drivers-Jonathan-Corbet/dp/0596005903/) and ["Understanding the Linux Kernel", Daniel P. Bovet](https://www.amazon.com/Understanding-Linux-Kernel-Third-Daniel/dp/0596005652). In addition, read and _understand_ the code. Make use of [LXR](http://lxr.free-electrons.com).

When kobjects are embedded inside other structures, the structures receive the standardized functions that a kobject provides. Most importantly, the structure's embedded kobject now enables the structure to become part of an object hierarchy. For example the cdev structure is presentable in an object hierarchy via the parent pointer cdev->kobj.parent and the list cdev->kobj.entry

Source: Linux Kernel Development by Robert Love

For general kernel module writing tips, you can read the books:Linux Kernel Development, Linux Kernel in a Nutshell and Linux Device Drivers.

After you understand the basics on how to build & install your own kernel modules, you can read the source code of the kernel to figure out where the framebuffer stuff is (start at Documentation/fb/framebuffer.txt). I'm not sure whether you can just hook up on the framebuffer driver like that, if not, you might need to add the hook support yourself or 'hijack' the main driver's events to simulate hooking. For example, suppose that there's a function that is called whenever there's an update. You find where the pointer to this function is declared, save the value, then modify it with a pointer to your function. Inside your function you call the original function, then your own code to manipulate what you want and return properly.

I don't know much about the framebuffer stuff, so I'm just guessing what your options are. It's possible that there might be a discussion list somewhere specific to the subject of linux-fb. This might me a good start.

The kernel does not know that this particular interrupt is for a particular device.

The only thing it knows is that it must call irq_handler with raspi_gpio_devp as a parameter. (like this: irq_handler(irq, raspi_gpio_devp)).

If your irq line is shared, you should check if your device generated an IRQ or not. Code:

int irq_handler(int irq, void* dev_id) {
    struct raspi_gpio_dev *raspi_gpio_devp = (struct raspi_gpio_dev *) dev_id;
    if (!my_gpio_irq_occured(raspi_gpio_devp))
        return IRQ_NONE;
    /* do stuff here */
    return IRQ_HANDLED;
}

The interrupt handler runs in interrupt context. But you can access static variables declared outside the scope of the interrupt.

Usually, what an interrupt handler does is:

• check interrupt status
• retrieve information from the hardware and store it somewhere (a buffer/fifo for example)
• wake_up() a kernel process waiting for that information

If you want to be really confident with the do and don't of interrupt handling, the best thing to read about is what a process is for the kernel.

An excellent book dealing with this is Linux Kernel Developpement by Robert Love.

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.

[0] https://www.amazon.com/RHCSA-RHCE-Red-Enterprise-Linux/dp/14...

[1] https://www.amazon.com/Practical-Guide-Commands-Editors-Prog...

[2] https://www.amazon.com/Advanced-Programming-UNIX-Environment...

[3] https://www.amazon.com/Linux-Programming-Interface-System-Ha...

[4] https://www.amazon.com/Linux-Kernel-Development-Robert-Love/...

[5] https://www.amazon.com/How-Linux-Works-Superuser-Should/dp/1...

[6] https://www.amazon.com/Linux-Command-Line-Complete-Introduct...

[7] https://www.amazon.com/Python-Crash-Course-Hands-Project-Bas...

[8] https://www.amazon.com/Automate-Boring-Stuff-Python-Programm...

Hit the books? That's what I do, I'm reading this one for fun now: https://www.amazon.com/Linux-Kernel-Development-Robert-Love/...

It's awesome. I have a library stacked full of software and CS books. Maybe try to get your bachelors at night? I got my master's at night while working.

This is a craft. If you want to be an expert, train like an expert. Realize 3 months of a bootcamp isn't going to cut it, not at least until you've been working for 4, 6, 8 years.

If you can't tell me what inter process communication is, what it's used for, pipes, signals, etc. then I think you have some pretty big gaps in knowledge that preclude you from being an expert at this point.

https://www.amazon.com/Linux-Kernel-Development-Robert-Love/... is very good, as is https://www.amazon.com/Mac-OS-iOS-Internals-Apples/dp/111805...

The most thorough treatment is Bovet & Cesati (944 pages): http://www.amazon.com/Understanding-Linux-Kernel-Third-Editi...

A good "gentle introduction" book is the Love book (440 pages): http://www.amazon.com/Linux-Kernel-Development-Robert-Love/d...

I have been keeping a list of books I used to augment my CS Masters Degree courses on various topics, here are the relevant ones I have found useful for the topics you have listed:

--Computer Organization--:

Computer Systems: A Programmer's Perspective http://www.amazon.com/Computer-Systems-Programmers-Randal-Br...

I liked this much better than Computer Organization and Design by Patterson and Hennessy which everyone has encountered at some point. The developer-centric view was very cool.

--Computer Security--:

Kernel Exploitation: Attacking the Core http://www.amazon.com/Guide-Kernel-Exploitation-Attacking-Co...

Most 'hacking' books are goofy. This one is very good and doubles nicely as a hackers operating systems text.

Web Application Hackers Handbook http://www.amazon.com/Web-Application-Hackers-Handbook-Disco...

Very nice overview for web concerns.

--Operating Systems-:

Operating System Design and Implementation http://www.amazon.com/Operating-Systems-Design-Implementatio...

I don't agree with Tanenbaum's views on micro vs. monolithic kernels but this book is a great mix of theory and implementation.

Linux Kernel Devleopment http://www.amazon.com/Linux-Kernel-Development-Robert-Love/d...

I used this to get a feel for the monolithic implementations of topics covered by Tanenbaum.

--Networking--:

TCP/IP Illustrated Series. More than you would ever want to know.

I'd also add Love's Linux Kernel Development[2], published in 2010. Great resource overall for someone wanting to go developing the internals of the kernel.

[2]