Tutorials :: The Linux Channel

Many viewers and even sometimes my students ask me how I can become a kernel programmer or just device driver developer and so on. So I shot this video (and an add-on video) where I summarized steps and a roadmap to become a full-fledged Linux Kernel Developer.

Whenever you do custom kernel modules, you can optionally make it a part of existing Linux Kernel source. This does not mean you are submitting your kernel module to the mainline kernel source (i.e kernel.org Linux Kernel Foundation). What I meant is, you can make your kernel module(s) part of Linux Kernel source so that when you compile your kernel you can automatically compile your kernel module(s) too. As well when you create/modify kernel .config configuration file (such as via make menuconfig, etc), you can enable or disable your kernel module(s) too.
To do the same you have to register (and include) your custom Kernel Module's Kconfig and Makefile to the existing Kconfig and Makefile of the Linux Kernel source Here is a detailed multi-episode video of mine which gives the overall idea and the big-picture.

When learning Linux Kernel programming, often I notice my students and viewers gets confused and they start with learning writing Linux Kernel modules. And so they develop the common misconception about Kernel Programming in general. They assume writing code in Linux Kernel means writing kernel modules. Which is absolutely not. Kernel modules are an optional choice and are part of Linux Kernel. But besides modules, Linux Kernel has lot of other mainstream code. Hence if anyone wants to be a Kernel Developer, you should be aware that sometimes you add new code via modules, sometimes without them. And if you ask me, I am not much in favor of writing Kernel modules. Instead in my code, I try to integrate and make them a part of Linux Kernel so that they all get initialized during boot time. Here is an extensive Youtube video of mine on Linux Kernel Programming, with and without Kernel Modules.

Here is a my multi-episode Youtube video series of me doing a live code (Code with Kiran Series). Linux Kernel source consists of many libraries within. For example such as to create and manage Linked Lists, String Operations, Encryption Algorithms, Compression Algorithms, and so on. In the Kernel, various Kernel Modules (including various Device Drivers) will use these Kernel inclusive Libraries. Unlike user-space programming, in Kernel Space when you code, you have to use these Libraries which are actually part of kernel (i.e sharing the same address space). And in some cases you can also make your own libraries and publish as well. In the case of user-space programs, we use third-party libraries (explicit or implicit), but that cannot happen when you code in kernel space. The libraries share the same address space and they are part of Linux Kernel mainline source. Hence it is important to understand the significance of using such library as demonstrated in my video series bel

Here is a my multi-episode Youtube video series of me doing a live code (Code with Kiran Series). Linux Kernel GPIO drivers of Raspberry Pi offers access/control directly via sysfs filesystem interface. But often people don't see this aspect, instead as a part of IoT, they assume these GPIO pins can be only accessed by some Python, Java or C/C++ code libraries. But in the real case those libraries are just an abstract layer written around the core Kernel GPIO driver's sysfs filesystem. So here is an attempt where we learn this aspect in systems architecture point of view. And then later try to attempt writing such user-space GPIO control code without any third-party libraries. Since the sysfs driver access is via regular files (user-space context), we can now use any language of our choice and access the same like any files. In that process we can attempt writing our own bunch of abstract APIs resembling a typical GPIO access library.

Here is a detailed Youtube video on Linux Kernel custom compilation and customization via make menuconfig interface

Learning Linux Kernel Programming is always fascinating and yet challenging. So generally you may tend to learn Kernel Module programming, since such a module can be dynamically plugged into running Linux Kernel. But this will lead to confusion, and many assume kernel source is mostly a collection of these modules. Which in reality is not. Not just that, when we say Kernel Module, its a vaguely defined term. The term Module (as we know) is nothing but a collection of APIs, bunch of variables and associated data-structures. Which may or may not be a plugable kernel module. If you ask me, I am a fan of wiring Linux Kernel Modules, which may not be necessarily a pluggable kernel module. It all boils down to the address space at which these modules function inside a monolithic Linux Kernel. Which is nothing but Linux Kernel's address space. Hence here is my detailed multi-episode Youtube video series on Linux Kernel modules, a big picture and the significance of the

Today I'm writing about linux kernel patch Philosophy. Oh yes, You are right submitting kernel patches is none less than a Philosophy.

Linux Kernel Tasklets and Work queues are somewhat similar to user-space process threads in terms of the functionality and of course not in terms of its operation or its internal architecture. You can schedule Tasklet(s) for a registered function to run later. So typically the Interrupt top half (of the interrupt handler) performs a small amount of critical work (not to be confused with critical section), and then schedules such as a tasklet to execute later at the bottom half.

Here is a detailed Youtube video on tracking Linux Kernel bugs via Kernel.org Bugzilla (or Bugzee as we call it in the Industry)

The Linux kernel is the backbone of the Linux operating system. A device tree is a hierarchical tree structure that describes the various devices that are present in a system, including their properties and relationships to one another. The device tree is used by the Linux kernel to identify and initialize the different devices on a system, and to provide a consistent interface for interacting with them.