Reading notes 125

Chapter One introduction to the Linux Kernel 1.1 UNIX history

• Because UNIX systems are designed to be concise and provide source code at the time of release, many other organizations and groups have further developed it.
• Although Unⅸ has been used for 40 years, computer scientists still consider it to be the most powerful and excellent system in the existing operating system. Since the birth of 1969, this UNIX product, inspired by Dennis Ritchie and Ken Thompson, has become legendary, and it has survived the test of time.

1.2 Tracking Linus Footprint: Introduction to Linux 1.3 operating system and kernel

The scope of the processor's activity at any given point in time can be summarized as one of the following three:

• Runs in kernel space, is in the process context, and executes on behalf of a particular process.
• Runs in kernel space, is in the interrupt context, is independent of any process, and handles a specific interrupt.
• Runs in user space and executes user processes.

Comparison of 1.4 Linux kernel and traditional Unix kernel

Comparison of features between Linux kernel and traditional Unix kernel

• Linux supports dynamic loading of kernel modules.
• Linux supports symmetric multi-processing (SMP) mechanisms
• The Linux kernel can be preempted.
• The Linux kernel does not differentiate between threads and other general processes

1.5 Linux kernel version

Naming rules:

1.6 Linux Kernel Developer community

The most important forum for this community: Linux kernel mailing list (LKML)

1.7 Summary chapter II starting from the kernel

This chapter introduces some basic knowledge of the Linux kernel: where to get the source code, how to compile it, and how to install the new kernel.

2.1 Getting the kernel source

• On the official Linux kernel website http://www.kernel.org, you can get the current version of the Linux source code at any time, either as a full compression or as an incremental patch.
• Unless you need an older version of Linux source in special cases, you'll want the latest code. Kernel.org is the repository of source code, and the incremental patches released by the core developers who lead the trend are also placed here.

2.1.1 Installing kernel source code using Git2.1.2

• If the compression form is bzip2, run:
  $ tar xvjf linux-x.y.z.tar.bz2
• If the compressed form is the GNU zip, run
  $ tar xvzf linux-x.y.z.tar.gz
  The extracted source code is located in the linux-x.y.z. Directory.
• Where to install Source code: The kernel source code is generally installed in the/usr/src/linux directory.

2.1.3 Using Patches

• The kernel version is constantly being updated, and incremental patches can be used as a bridge for version transfer.
• Advantages: Save bandwidth and save time
• To apply incremental patches, start with your internal source tree and just run:
  $ Patch P1 <: /patch-x.y.z
• Generally speaking, a given version of the kernel patch is always hit on the previous version

2.2 Kernel source Tree

The kernel source tree consists of many directories, and most directories contain more subdirectories. The root directory of the source tree and its subdirectories are shown in the table.

目录  描述arch    特定体系结构的源码crypto  Crypto APIDocumentation   内核源码文档drivers 设备驱动程序fs  VFS和各种文件系统include 内核头文件init    内核引导和初始化ipc 进程间通信代码kernel  像调度程序这样的核心子系统lib 通用内核函数mm  内存管理子系统和VMnet 网络子系统scripts 编译内核所用的脚本security    Linux安全模块sound   语音子系统usr 早期用户空间代码 (所谓的 initramfs)

2.3 Compiling kernel 2.3.1 configuration kernel

• Before compiling the kernel, you must first configure it.
• The various options that can be configured are expressed in config_feature form with the prefix config.
• Configuration options can be used to determine which files are compiled into the kernel or to process code through preprocessing commands.
• These configuration items are either two selected or three selected. The second choice is yes or No. For example, Config_preempt is the second choice, indicating whether the kernel preemption function is turned on. Three choices can be yes, no, or module. The module means that the configuration item is selected, but the implementation code for this part of the feature is generated in the form of a module, a standalone piece of code that can be dynamically installed. In the case of three choices, the Yes option means that the code is compiled into the master kernel image, not as a module. Drivers typically use three to select one of the configuration items.

2.3.2 Reduce compilation of junk information

• We want to see error and warning messages at compile time, but not interested in the spam that is rushing over the screen, you can use the following techniques to achieve your wishes:
  Make > Some_other_file
• Once you need to view the compiled output information, you can view the file. However, because errors and warnings are displayed on the screen, it is unlikely that you will need to see this file. Actually, I just typed in the following command.
  $ make >/dev/null
  This redirects useless output information to a black hole/dev/null with no return value.

2.3.3 Derivation of multiple compilation jobs

• In order to compile the kernel with multiple jobs, use the following command:
  $ make-jn
• Here, N is the number of jobs to be derived, and in practice, one or two jobs are generally derived from each processor. For example, on a dual processor, you can enter the following command:
  $ make–j4

2.3.4 Installing a new kernel

• The installation of the module is automatic and independent of the architecture. As Root, just run:
  % make Modules_install
  You can install all the compiled modules into the correct home directory/lib.

2.4 Features of kernel development

Differences between Linux kernel programming and application development in user space

• Linux kernel cannot access C library when programming
• The Linux kernel must be programmed with the GNU C
• Linux kernel programming lacks the memory protection mechanism like user space.
• Floating point numbers are difficult to use when programming the Linux kernel.
• The kernel has only a small fixed-length stack.
• Because the kernel supports asynchronous interrupts, preemption, and SMP, you must always be aware of synchronization and concurrency.
• Consider the importance of portability.

2.4.1 No libc library or no standard header file

• Most of the commonly used C library functions have been implemented in the kernel. For example, a function group that operates on a string is located in the Lib/string.c file. You can use them as long as you include the <linux/string.h> header files.
• Of all the functions that are not implemented, the most famous is the printf () function. Although the kernel code cannot call printf (), it can call the PRINTK () function.

2.4.2 GNU C

The C language used by kernel developers covers the ISO C995 standard and GNU C extension features.

• inline (inline) functions
• inline assembly
• Branch Declaration

2.4.3 No memory protection mechanism

• If a user program tries to make an illegal memory visit, the kernel discovers the error, sends the SIGSEGV, and ends the process.
• Memory errors that occur in the kernel cause oops, which is the most common type of error that occurs in the kernel.
• The memory in the kernel is not paged.

2.4.4 do not use floating-point numbers easily in the kernel

• What happens when you execute a floating-point instruction, because the architecture is different, the kernel chooses differently, but the kernel usually catches traps and handles them accordingly.
• Unlike the user-space process, the kernel does not perfectly support floating-point operations because it cannot be caught in itself .

2.4.5 volume small and fixed stack

• The exact size of the kernel stack changes with the architecture. On x86, the size of the stack is configured at compile time, which can be either 4KB or 8KB.
• Historically, the size of the kernel stack is two pages, which means that the 32-bit machine core stack is 8KB, and the 64-bit machine is 16KB, which is fixed.
• Each processor has its own stack.

2.4.6 Synchronization and concurrency

• Linux is a preemptive multitasking operating system. The kernel's process scheduler improvised scheduling and rescheduling of processes. The kernel must synchronize these tasks.
• The Linux kernel supports multi-processor systems.
• Interrupts come asynchronously, completely ignoring the code that is currently executing.
• The Linux kernel can be preempted.

The importance of 2.4.7 portability

• Linux is a portable operating system,
• The architecture-related code must be properly separated from the specific directory in the kernel tree.

5.1 Communication with the kernel 57

The system call adds a middle layer between the user space process and the hardware device, which has a primary role of three:

• First, it provides a hardware abstraction interface for user space, for example, when a file needs to be read and written, the application can do away with the type of disk and media, or even the file system in which the file resides.
• Second, system calls guarantee the stability and security of the system, and as a middleman between hardware devices and applications, the kernel can adjudicate the required access based on permissions, user types, and other rules, for example, to avoid improper use of hardware devices by applications, and to steal resources from other processes. Or to make other things that harm the system.
• Thirdly, as mentioned in the 3rd chapter, each process is run in a virtual system, and in the user space and the rest of the system to provide such a layer of public interface, but also for this reason, if the application can freely access the hardware and the kernel does not know about it, it is almost impossible to achieve multi-tasking and virtual memory, Of course, it is not possible to achieve good stability and security.

In Linux, system calls are user-space access. The only means of the kernel is that they are the only legitimate entry for the kernel except for exceptions and falls.
This chapter focuses on the rules and implementation methods of Linux system invocation.

5.2 API, POSIX, and C library 57

• In general, applications are programmed through application programming interfaces implemented in user space rather than directly through system tuning.
• The programming interface used by the application does not actually need to correspond to the system calls provided by the kernel. An API defines the programming interfaces used by a set of applications, which can be implemented as a system call, or by invoking multiple system calls, without any system calls being used at all.
• In fact, APIs can be implemented in a variety of operating systems, providing the exact same interface to applications, which can be implemented on these systems in different ways.
• The relationships between APIs, POSIX and C libraries, and system calls such as
  Figure A
• In the Unix world, the most popular application programming interface is based on the POSIX standard.
• The interface design for UNIX has a motto: to provide a mechanism rather than a strategy.

5.3 System Call 58

• To access system calls, it is usually done through function calls defined in the C library.
• The system call eventually has a definite operation.
• How to define a system call

First, note the Asmlinkage qualifier in the function declaration, which is a compilation instruction that notifies the compiler to extract only the parameters of the function from the stack. This qualifier is required for all system calls.
The next function returns a long. To ensure compatibility between 32-bit and 64-bit systems, system calls have different return value types in user space and kernel space, where the user space is int in kernel space is long.
Finally, note that the system call in Get_pid () is defined in the kernel as Sys_getpid (). This is the naming convention that all system calls in Linux should follow, and the system call Bar () is also implemented as the Sys_bar () function in the kernel.

5.3.1 System call Number 59

• In Linux, each system call is given a system call number.
  This makes it possible to associate system calls with this unique number.
  When a user-space process executes a system call, the system call number is used to indicate which system call is being executed.
• The system call number is quite important, and once the allocation is no longer changed, the compiled application crashes. In addition, if a system call is deleted, the system call number it occupies is not allowed to be recycled, otherwise the previously compiled code calls the system call, but in fact it calls another system call.
• Linux has an "not implemented" system call Sys_ni_syscall (), which does not do any other work except to return ―enosys, which is specifically designed for invalid system calls. Although rare, if a system call is deleted or becomes unavailable, this function is responsible for "filling the vacancy".
• The kernel records the list of all registered system calls in the system call table, stored in sys_call_table.
• In each architecture, the table is explicitly defined in x86-64, which is defined in the arch/i386/kernel/syscall_64.c file. This table specifies a unique system call number for each valid system call.

5.3.2 performance of system calls 59

The reason why the Linux system executes fast:

• Very short context switching time.
• System call handlers and each system call itself are also very concise.

5.4 System call Handlers 60

User-space programs cannot execute kernel code.
The mechanism for notifying the kernel is implemented by soft interrupts:

By throwing an exception that causes the system to switch to the kernel state to execute the exception handler, the exception handler is actually the system call handler, and the predefined soft interrupt on the x86 system is the interrupt number 128. This interrupt is triggered by the int￥0x80 instruction, which triggers an exception that causes the system to switch to the kernel state and execute the 128th exception handler, which is the system call handler, which is aptly named System_call (). It is closely related to the hardware architecture.

5.4.1 specifying the appropriate system call 60

• The system call number must be passed to the kernel.
• On x86, the system call number is passed to the kernel through the EAX register.

5.4.2 Parameter Passing 60

• In addition to the system calls, most system calls require some external parameter input.
• The simplest approach is to put these parameters in the register as well as passing the system call number.
• Figure 2
• The return value to the user space is also passed through the register. On the x86 system, it is stored in the EAX register.

5.5 Implementation of system call 615.5.1 implement system call 61

• Multi-purpose system calls are not advocated in Linux.
• What is the parameter, return value, and error code of the new system call? The interface of the system call should be concise and with as few parameters as possible. The semantics and behavior of system calls are critical, because applications depend on them, so they should be stable and do not make changes if the function changes many times.
• Can the new feature be appended to the system call or will it require a new function to make it easy to revise the error without destroying backwards compatibility? Many system calls provide flag parameters to ensure forward compatibility. Flags are not used to allow a single system call to have multiple different rows as described earlier, this is not allowed, but is intended to add new features and options, and does not break backwards compatibility or add new system calls.
• When designing interfaces, try to think about the future as much as possible. Do you have unnecessary restrictions on functions? The more general the system call is designed, the better. Don't assume that this system call is going to be used in the future. The purpose of the system call may be the same, but its usage may change.
• Is this system call portable? Do not assume the byte-length and byte-order of the machine. To make sure that the system calls do not make false assumptions, the call may crash in the future.

5.5.2 Parameter Validation 62

• System calls must be carefully checked to see if all of their arguments are valid. System calls execute in kernel space, and if the user passes the illegal input to the kernel, the security and stability of the system will be greatly tested; For example, system calls related to file I/O must check that the file descriptor is valid. Process-related functions must check that the provided PID is valid. Each parameter must be checked to ensure that they are not only valid, but also correct. A process should not allow the kernel to access resources that it does not have access to.
• One of the most important checks is to check whether a user-supplied pointer is valid. Imagine that if a process can pass pointers to the kernel without checking, then it can give a pointer to it that does not have access, and spoof the kernel to copy data that it does not allow to access, such as data that originally belonged to other processes or unreadable mapping data. Before receiving a pointer to a user space, the kernel must ensure that:

1. The memory area pointed to by the pointer belongs to the user space, and the process must not spoof the kernel to read the data in the kernel space.
2. The memory area that the pointer points to in the address space of the process, the process must not spoof the kernel to read data from other processes.
3. If it is read, the memory should be marked as readable, if it is write, the memory should be marked as writable, and if it is executable, the memory is marked as executable. The process must not bypass the memory access permissions.

5.6 System Invoke Context 64

• The kernel is in a process context when it executes system calls.
• In the context of a process, the kernel can hibernate and can be preempted.
• When the system call returns, control is still in System_call (), and it will eventually be responsible for switching to user space and letting the user process continue.

5.6.1 binding a system call the last step 65

When a system call is written, registering it as a formal system call is trivial work:

1. First, add a table entry at the end of the system call table. Every hardware system that supports this system call must do the work (most system calls are for all architectures) starting with 0, where the system call is the system call number in the table. As the 10th system call is assigned to the system call number 9)
2. For each of the supported architectures, the system call number must be defined in <asm/unistd.h>.
3. The system call must be compiled into the kernel image (cannot be compiled into a module). This just puts it in a related file under the kernel/, like SYS.C, which contains a variety of system calls.

5.6.2 accessing system calls from User space 67

• Typically, system calls are supported by the C library.
• Linux itself provides a set of macros.

5.6.3 why not implement a system call by means of 68

The benefits of building a new system call

• System calls are easy to create and easier to use.
• The high performance of Linux system calls is obvious.

Problem is

• You need a system call number, which requires a kernel to be assigned to you by the official when it is in the development version.
• System calls need to be registered separately in each architecture that needs to be supported.
• It is not easy to invoke a system call in a script, nor can it directly access system calls from the file system.
• Because you need the system call number, it is difficult to maintain and use system calls outside of the main kernel tree. If you simply make a simple information Exchange system call, you are overqualified. Workaround: Implement a Device node and implement read () and write () for this. Use specific information for retrieval.
• Some interfaces, such as semaphores, can be represented by file descriptors, so they can be manipulated in the same way
• Put the added information as a file in the right place of the SYSFS.

Reading notes 125