Quora User Thanks for your cool idea. Yes, chattr can be used to set the immutable bit on many Linux file systems, but you know super administrators like root can change that bit too. I wanna hook such system calls as OPEN, CREAT and WRITE to protect key directories and files from being modified. If my hook program is running, even super administrators cannot modify these key directories and files. I tried to modify the SYSCALL table, and it worked on some versions of Linux kernels, and didn’t on other versions. I am not going to implement a new filesystem, I just wanna add new features to the existing ones. I prefer to add new feature to the virtual file system, is that possible? Tracing chattr is a good idea, I’ll have a try.

It is quite simple. Each PCI/PCIe device needs to implement few basic registers which include vendor and device ids. When the Linux PCI driver (drivers/pci) scans the PCI bus and builds the PCI config tree, it basically reads these registers among others. All the device drivers have to do is to register the driver with proper vendor and device ids for which the driver is written. These drivers also register appropriate operations (depends on what class of device it is) structure with the kernel. Kernel checks the PCI ID table specified by the driver with the one stored in the PCI config space and associates the device with the driver and calls the probe entry point in the driver. Probe entry point allocates all the resources needed by the device and "claims" the device. Once the device is claimed by the driver, all operations on the device land up in the driver.

The LKM is an object file not an executable which means that the functions/symbols are not relocated yet. So, why is this happening? Because we dont have the idea of a shared library in the linux kernel. So if a LKM wants to make use of a function say "X" which is part of the linux kernel, then the symbol needs to be exported using EXPORT_SYMBOL macro which adds the function to the kernel symbol table. The previous step is done in the linux kernel code not in the custom LKM. The module loader fixes the relocation and if it encounters a symbol that is not part of the kernel but part of another known LKM, it loads that LKM first, this is what the modprobe does . Also, if you want to verify what all functions/symbols are exported by the linux kernel from user space, you can view the /proc/kallsyms! To answer your question short, symbols exported by the linux kernel "acts" as shared library for the LKM so that you can reuse the code! These relocations are fixed by the LKM loader which is part of the kernel!

Kernel Stack is dependent on architecture. On x86 it is 2 pages, which implies 8KB on 32-bit and 16KB on 64-Bit. It is defined as an array of unsigned long. And struct thread_info is 52 bytes. struct thread_info is stored at the bottom of stack if stack grows down and up if stack grows up. Let, Kernel Stack is 8KB of size. Also, it should have struct thread_info in it. This gives the remaining size of 8192-52 = 8140 Bytes. Whole of this could be represented as a struct or as a union. If both of them is binded as a struct, then we would have something like this:
Each long is a size of 4 Bytes, hence for 8140 Bytes size of long array should contains 8140/4 = 2035 elements.

struct thread_struct 
{ 
    struct thread_info thread_info; //52 Bytes long 
    unsigned long stack [2035]; 
}; 

Hence, total size is 8192 bytes.

Now consider a union. In union, the size of union is the maximum size of all the fields. So, to have a union of size 8KB, we can have the array of unsigned long as 8KB or an array of unsigned long with 8192/4 = 2048 elements. Hence, we have

struct thread_union 
{ 
    struct thread_info thread_info; 
    unsigned long stack [2048]; 
}; 

It is easy to represent in the form of union. Moreover, thread_info and stack share the memory space. It is not like that both of their space is added up to give 8KB, they both share that space.

Hi Santhosh,

In case of embedded Linux kernels, we do have board files defined under arch/arm/mach-<xxx>, in which the devices present on the board and the corresponding arguments for devices drivers are listed.

While kernel boots up, during the init calls, the drivers are registered against their names. After which while processing the platform device list, it is matched up against the registered list of drivers. On hitting a match, the corresponding driver probe function is invoked (passing pointer to platform data) to initialize the required functionality - such as interrupts, pin configurations, handlers etc.

Now in the case PCI, the hardware shows up like a memory mapped interface (it was similar in case of Marvell's PXA platform, which I worked on, on x86 it might be through BIOS or some other mechanism but it will be similar), through which we can interact with the hardware. The first few block of memory for any PCI based device will have a descriptor kind of region which will contain information such as vendor-id, device-id, subclass, revision etc.

In Linux, the drivers while registering itself will export a pci_device_id table along with probe and other relevant information. Here is an example I took from LDD3

<snip>

static struct pci_device_id i810_ids[ ] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810_IG1) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810_IG3) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810E_IG) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82815_CGC) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82845G_IG) },
{ 0, },
};

static struct pci_driver pci_driver = {
.name = "pci_skel",
.id_table = i810_ids,
.probe = probe,
.remove = remove,
};

</snip>

You can think of more like a driver informing kernel that these are the devices it is compatible with.

Now, when a PCI device is identified, Linux matches up against the registered device drivers (from the table registered earlier). On finding a match, it invokes the probe function of the same and starts off with rest of the processing and registration activities

you can get more insight in to PCI driver probe and registration sequence in the following links:

• Page on Lwn
• 12.1. The PCI Interface

Hope this clears your doubt :)

Kernel modules really refer to several different kinds of kernel code, just compiled into a “plugin” or module. Many aspects of kernel code can be compiled “as a module” or “compiled into the kernel”.

What makes something modular is that it exports an initialization routine, and an exit or cleanup routine. In code, you’ll see this in source code files like this:

MODULE_INIT(function_name) 
MODULE_EXIT(other_function_name) 

When you insert the module into a running kernel, by calling “insmod”, the init function runs. This is where you might allocate memory or do other actions to “set up” the functionality in your module. At “rmmod”, the exit routine runs, and this is a place to clean up and make sure you’ve freed any memory used by your module.

Other than that, modules can really refer to a bunch of different things, and “how they integrate” will depend on what kind of kernel code it is. If it’s a block device driver, it will then follow the API for block devices, if it’s a filesystem loaded as a module, it will follow filesystem APIs, etc.

A kernel module is a pre-compiled code that can be loaded into memory at runtime upon demand. In modern systems the kernel modules are automatically loaded by specific mechanisms when there is a need arising.

The linux kernel is modular and therefore, this design makes it faster to load the kernel into the memory. Modules extend the functionality of the kernel without the need to reboot the system. The kernel need not load and initialize all the unnecessary modules. Also at the time of developing device drivers when you have a problem/bug, one can unload the module, rectify it, compile it and then load it. There are many uses of this type of design.

1. It saves RAM space.
2. Modules can be independently compiled and loaded.
3. Skipping the need to rebuild the kernel or reboot the device when you add a new module or load a module respectively.

Loadable Kernel Modules (or LKMs for short) are a way to extend a running kernel to deal with something new or unusual. A way to understand why these are useful is discussed in this question: Why are kernel modules useful? but for the sake of convenience, I’ll note a few things here as well.

1. Not all drivers are used.
   If you are like most people, you don’t compile your own kernel specifically to your own machine but use a distribution (Fedora, ubuntu, etc.) provided kernel. Usually kernel maintainers of such distributions package up one kernel and send it off to everyone. Interestingly enough, somebody far away from you maybe running a network card that you don’t have. However, without LKMs, your kernel would have to contain the code required to handle that network card you do not have, wasting RAM. If you have LKMs, then you can just compile the driver as a module and load it *if and only if* you have that specific network card.
2. For developers, if you are making a new feature often times, wrapping it in a module is enough and allows for faster iterations as you can unload a module and load the newer version straight away.

Nota bene, recent versions of the Linux kernel use the .ko extension to denote these modules and are often found in /usr/lib/modules or similar folder.

Kernel threads is a running kernel modules loaded to be run on one CPU:

“ps -ef” gives (noticed how many copies jfsCommit exists - since each of them is scheduled to run on one CPU (it is possible to have more than one of the same kernel modules running on the same CPU as different threads too, looked at “kworker”):

tteikhua 29186 23443  0 07:33 pts/16   00:00:00 ps -ef 
root     31175     2  0 Sep19 ?        00:00:00 [xfsalloc] 
root     31176     2  0 Sep19 ?        00:00:00 [xfs_mru_cache] 
root     31181     2  0 Sep19 ?        00:00:00 [jfsIO] 
root     31182     2  0 Sep19 ?        00:00:00 [jfsCommit] 
root     31183     2  0 Sep19 ?        00:00:00 [jfsCommit] 
root     31184     2  0 Sep19 ?        00:00:00 [jfsCommit] 
root     31185     2  0 Sep19 ?        00:00:00 [jfsCommit] 
root     31186     2  0 Sep19 ?        00:00:00 [jfsCommit] 
root     31187     2  0 Sep19 ?        00:00:00 [jfsCommit] 
root     31188     2  0 Sep19 ?        00:00:00 [jfsSync] 

And the kernel module is just a dynamic ELF file which can be loaded into the kernel.

Overview of Operating Systems and Kernels

Because of the ever-growing feature set and ill design of some modern commercial operating systems, the notion of what precisely defines an operating system is vague. Many users consider whatever they see on the screen to be the operating system. Technically speaking, and in this book, the operating system is considered the parts of the system responsible for basic use and administration. This includes the kernel and device drivers, boot loader, command shell or other user interface, and basic file and system utilities. It is the stuff you neednot a web browser or music players. The term system, in turn, refers to the operating system and all the applications running on top of it.

Of course, the topic of this book is the kernel. Whereas the user interface is the outermost portion of the operating system, the kernel is the innermost. It is the core internals; the software that provides basic services for all other parts of the system, manages hardware, and distributes system resources. The kernel is sometimes referred to as the supervisor, core, or internals of the operating system. Typical components of a kernel are interrupt handlers to service interrupt requests, a scheduler to share processor time among multiple processes, a memory management system to manage process address spaces, and system services such as networking and interprocess communication. On modern systems with protected memory management units, the kernel typically resides in an elevated system state compared to normal user applications. This includes a protected memory space and full access to the hardware. This system state and memory space is collectively referred to as kernel-space. Conversely, user applications execute in user-space. They see a subset of the machine's available resources and are unable to perform certain system functions, directly access hardware, or otherwise misbehave (without consequences, such as their death, anyhow). When executing the kernel, the system is in kernel-space executing in kernel mode, as opposed to normal user execution in user-space executing in user mode. Applications running on the system communicate with the kernel via system calls (see Figure 1.1). An application typically calls functions in a libraryfor example, the C librarythat in turn rely on the system call interface to instruct the kernel to carry out tasks on their behalf. Some library calls provide many features not found in the system call, and thus, calling into the kernel is just one step in an otherwise large function. For example, consider the familiar

should (you hope) make no use of the kernel at all. When an application executes a system call, it is said that the kernel is executing on behalf of the application. Furthermore, the application is said to be executing a system call in kernel-space, and the kernel is running in process context. This relationshipthat applications call into the kernel via the system call interfaceis the fundamental manner in which applications get work done.

Figure 1.1. Relationship between applications, the kernel, and hardware.

The kernel also manages the system's hardware. Nearly all architectures, including all systems that Linux supports, provide the concept of interrupts. When hardware wants to communicate with the system, it issues an interrupt that asynchronously interrupts the kernel. Interrupts are identified by a number. The kernel uses the number to execute a specific interrupt handler to process and respond to the interrupt. For example, as you type, the keyboard controller issues an interrupt to let the system know that there is new data in the keyboard buffer. The kernel notes the interrupt number being issued and executes the correct interrupt handler. The interrupt handler processes the keyboard data and lets the keyboard controller know it is ready for more data. To provide synchronization, the kernel can usually disable interruptseither all interrupts or just one specific interrupt number. In many operating systems, including Linux, the interrupt handlers do not run in a process context. Instead, they run in a special interrupt context that is not associated with any process. This special context exists solely to let an interrupt handler quickly respond to an interrupt, and then exit.

These contexts represent the breadth of the kernel's activities. In fact, in Linux, we can generalize that each processor is doing one of three things at any given moment:

• In kernel-space, in process context, executing on behalf of a specific process
• In kernel-space, in interrupt context, not associated with a process, handling an interrupt
• In user-space, executing user code in a process

This list is inclusive. Even corner cases fit into one of these three activities: For example, when idle, it turns out that the kernel is executing an idle process in process context in the kernel.

There are several good books on Linux kernel programming. Linux Device Drivers is available online as well as on paper. Chapter 5 deals with concurrency; you can jump in directly to chapter 5 though it would be best to skim through at least chapters 1 and 3 first. Subsequent chapters have relevant sections as well (in particular wait queues are discussed in chapter 6).

The Linux kernel concurrency model is built on shared variables. There is a large range of synchronization methods: atomic integer variables, mutual exclusion locks (spinlocks for nonblocking critical sections, semaphores for blocking critical sections), reader-writer locks, condition variables, wait queues, …

Credits : Gilles on stackoverflow.

How do I run "invd" instruction from a kernel module?

Depends on the operating system and what you are trying to do.

The invd instruction itself wipes out cache. So using it in most kernel modules is not something you want to do as it will destroy the performance of the system.

It MIGHT be what you want when performing a context switch, but almost never at any other time. Context switching is not something done in a module.

Now MOST C compilers have an assembly language option (asm(“the line of assembly”)), and that allows you to embed some assembly in C.

It is nonportable to use it though, so such operations are usually in an architecture specific library instead.