深入解析Linux内核2.4：启动、进程与中断管理

Linux，Kernel，技术

需积分: 9 103 浏览量更新于2024-07-28 收藏 252KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"Linux Kernel 2.4 Internals" 是一本深入解析 Linux 内核 2.4 版本的书籍，由 Tigran Aivazian 编写。本书涵盖了广泛的 Linux 内核技术细节，包括启动流程、进程与中断管理、虚拟文件系统（VFS）、页面缓存、IPC 机制等多个核心主题。 1. 启动 - 构建 Linux 内核镜像：书中详细介绍了如何构建符合特定需求的 Linux 内核映像。 - 启动概述：涵盖了从 BIOS POST 到操作系统加载的整体流程。 - BIOS POST：计算机启动时的基本输入输出系统执行的硬件自检过程。 - 引导扇区和 setup：这部分内容讨论了引导扇区和 setup 程序在启动过程中的作用。 - 使用 LILO 引导装载器：LILO 是早期常用的 Linux 引导装载程序，书中解释了如何配置和使用它。 - 高级初始化：涉及 Linux 内核在引导过程中的高级设置，如硬件检测和初始化。 - SMP 启动在 x86 平台：针对多处理器系统（SMP）的启动步骤。 - 释放初始化数据和代码：系统启动后，如何释放不再需要的初始化资源。 - 处理内核命令行参数：内核如何解析并应用启动时的命令行参数。 2. 进程与中断管理 - 任务结构与进程表：介绍 Linux 中进程的内部表示及其管理的数据结构。 - 任务创建与终止：详细讲解如何创建和结束任务（进程和内核线程）。 - Linux 调度器：内核调度算法的实现，包括抢占、时间片分配等。 - Linux 链表实现：内核中广泛使用的链表数据结构。 - 等待队列：等待事件发生时，进程如何进入睡眠状态。 - 内核定时器：用于设置定时事件的机制。 - 底部半部：处理中断后延迟执行的任务。 - 任务队列：管理一组待执行任务的机制。 - 任务片：轻量级的异步任务执行方式。 - 软中断：非中断源触发的快速处理机制。 - i386 架构下的系统调用实现：解释了在 386 架构下如何实现系统调用。 - 原子操作：确保操作不会被中断的低级别编程技术。 - 自旋锁、读-写自旋锁和大读者自旋锁：并发控制机制。 - 信号量和读/写信号量：同步原语，用于保护共享资源。 - 内核对模块加载的支持：如何动态添加或删除内核模块。 3. 虚拟文件系统 (VFS)： VFS 是 Linux 内核的一个关键部分，它提供了一个统一的接口，使不同的文件系统可以透明地挂载和访问。VFS 包括文件描述符管理、打开、关闭、读写、查找文件等功能，并允许不同类型的文件系统（如 ext2、ext3、NTFS 等）在内核中协同工作。 4. 页面缓存 (Linux Page Cache)：页面缓存是 Linux 内核提高 I/O 效率的关键机制，通过将磁盘上的数据缓存到内存中，减少了对物理磁盘的访问次数。 5. IPC 机制：进程间通信 (IPC) 机制允许不同进程之间交换信息，如信号量、消息队列、共享内存等。本书为理解 Linux 内核的工作原理提供了丰富的资料，对于开发者、系统管理员和 Linux 爱好者来说，是一本宝贵的参考资料。通过学习，读者能够深入了解 Linux 内核的设计理念和实现细节，从而更好地优化和调试系统。

资源详情

资源推荐

1.7 SMP Bootup on x86

On SMP, the BP goes through the normal sequence of bootsector, setup etc until it reaches the

start_kernel(), and then on to smp_init() and especially

src/i386/kernel/smpboot.c:smp_boot_cpus(). The smp_boot_cpus() goes in a loop for

each apicid (until NR_CPUS) and calls do_boot_cpu() on it. What do_boot_cpu() does is create (i.e.

fork_by_hand) an idle task for the target cpu and write in well−known locations defined by the Intel MP

spec (0x467/0x469) the EIP of trampoline code found in trampoline.S. Then it generates STARTUP IPI

to the target cpu which makes this AP execute the code in trampoline.S.

The boot CPU creates a copy of trampoline code for each CPU in low memory. The AP code writes a magic

number in its own code which is verified by the BP to make sure that AP is executing the trampoline code.

The requirement that trampoline code must be in low memory is enforced by the Intel MP specification.

The trampoline code simply sets %bx register to 1, enters protected mode and jumps to startup_32 which is

the main entry to arch/i386/kernel/head.S.

Now, the AP starts executing head.S and discovering that it is not a BP, it skips the code that clears BSS

and then enters initialize_secondary() which just enters the idle task for this CPU − recall that

init_tasks[cpu] was already initialised by BP executing do_boot_cpu(cpu).

Note that init_task can be shared but each idle thread must have its own TSS. This is why

init_tss[NR_CPUS] is an array.

1.8 Freeing initialisation data and code

When the operating system initialises itself, most of the code and data structures are never needed again. Most

operating systems (BSD, FreeBSD etc.) cannot dispose of this unneeded information, thus wasting precious

physical kernel memory. The excuse they use (see McKusick's 4.4BSD book) is that "the relevant code is

spread around various subsystems and so it is not feasible to free it". Linux, of course, cannot use such

excuses because under Linux "if something is possible in principle, then it is already implemented or

somebody is working on it".

So, as I said earlier, Linux kernel can only be compiled as an ELF binary, and now we find out the reason (or

one of the reasons) for that. The reason related to throwing away initialisation code/data is that Linux provides

two macros to be used:

__init − for initialisation code•

__initdata − for data•

These evaluate to gcc attribute specificators (also known as "gcc magic") as defined in

include/linux/init.h:

#ifndef MODULE

#define __init __attribute__ ((__section__ (".text.init")))

#define __initdata __attribute__ ((__section__ (".data.init")))

#else

#define __init

#define __initdata

#endif

Linux Kernel 2.4 Internals

1.7 SMP Bootup on x86 9

What this means is that if the code is compiled statically into the kernel (i.e. MODULE is not defined) then it

is placed in the special ELF section .text.init, which is declared in the linker map in

arch/i386/vmlinux.lds. Otherwise (i.e. if it is a module) the macros evaluate to nothing.

What happens during boot is that the "init" kernel thread (function init/main.c:init()) calls the

arch−specific function free_initmem() which frees all the pages between addresses __init_begin

and __init_end.

On a typical system (my workstation), this results in freeing about 260K of memory.

The functions registered via module_init() are placed in .initcall.init which is also freed in the

static case. The current trend in Linux, when designing a subsystem (not necessarily a module), is to provide

init/exit entry points from the early stages of design so that in the future, the subsystem in question can be

modularised if needed. Example of this is pipefs, see fs/pipe.c. Even if a given subsystem will never

become a module, e.g. bdflush (see fs/buffer.c), it is still nice and tidy to use the module_init()

macro against its initialisation function, provided it does not matter when exactly is the function called.

There are two more macros which work in a similar manner, called __exit and __exitdata, but they are

more directly connected to the module support and therefore will be explained in a later section.

1.9 Processing kernel command line

Let us recall what happens to the commandline passed to kernel during boot:

LILO (or BCP) accepts the commandline using BIOS keyboard services and stores it at a well−known

location in physical memory, as well as a signature saying that there is a valid commandline there.

arch/i386/kernel/head.S copies the first 2k of it out to the zeropage.2.

arch/i386/kernel/setup.c:parse_mem_cmdline() (called by setup_arch(), itself

called by start_kernel()) copies 256 bytes from zeropage into saved_command_line

which is displayed by /proc/cmdline. This same routine processes the "mem=" option if present

and makes appropriate adjustments to VM parameters.

We return to commandline in parse_options() (called by start_kernel()) which

processes some "in−kernel" parameters (currently "init=" and environment/arguments for init) and

passes each word to checksetup().

checksetup() goes through the code in ELF section .setup.init and invokes each function,

passing it the word if it matches. Note that using the return value of 0 from the function registered via

__setup(), it is possible to pass the same "variable=value" to more than one function with "value"

invalid to one and valid to another. Jeff Garzik commented: "hackers who do that get spanked :)"

Why? Because this is clearly ld−order specific, i.e. kernel linked in one order will have functionA

invoked before functionB and another will have it in reversed order, with the result depending on the

order.

So, how do we write code that processes boot commandline? We use the __setup() macro defined in

include/linux/init.h:

* Used for kernel command line parameter setup

struct kernel_param {

const char *str;

Linux Kernel 2.4 Internals

1.9 Processing kernel command line 10

max_threads = mempages / (THREAD_SIZE/PAGE_SIZE) / 2;

which, on IA32 architecture, basically means num_physpages/4. As an example, on a 512M machine, you

can create 32k threads. This is a considerable improvement over the 4k−epsilon limit for older (2.2 and

earlier) kernels. Moreover, this can be changed at runtime using the KERN_MAX_THREADS sysctl(2), or

simply using procfs interface to kernel tunables:

# cat /proc/sys/kernel/threads−max

32764

# echo 100000 > /proc/sys/kernel/threads−max

# cat /proc/sys/kernel/threads−max

100000

# gdb −q vmlinux /proc/kcore

Core was generated by `BOOT_IMAGE=240ac18 ro root=306 video=matrox:vesa:0x118'.

#0 0x0 in ?? ()

(gdb) p max_threads

$1 = 100000

The set of processes on the Linux system is represented as a collection of struct task_struct

structures which are linked in two ways:

as a hashtable, hashed by pid, and1.

as a circular, doubly−linked list using p−>next_task and p−>prev_task pointers.2.

The hashtable is called pidhash[] and is defined in include/linux/sched.h:

/* PID hashing. (shouldnt this be dynamic?) */

#define PIDHASH_SZ (4096 >> 2)

extern struct task_struct *pidhash[PIDHASH_SZ];

#define pid_hashfn(x) ((((x) >> 8) ^ (x)) & (PIDHASH_SZ − 1))

The tasks are hashed by their pid value and the above hashing function is supposed to distribute the elements

uniformly in their domain (0 to PID_MAX−1). The hashtable is used to quickly find a task by given pid, using

find_task_pid() inline from include/linux/sched.h:

static inline struct task_struct *find_task_by_pid(int pid)

{

struct task_struct *p, **htable = &pidhash[pid_hashfn(pid)];

for(p = *htable; p && p−>pid != pid; p = p−>pidhash_next)

;

return p;

}

The tasks on each hashlist (i.e. hashed to the same value) are linked by

p−>pidhash_next/pidhash_pprev which are used by hash_pid() and unhash_pid() to insert

and remove a given process into the hashtable. These are done under protection of the read−write spinlock

Linux Kernel 2.4 Internals

2. Process and Interrupt Management 12

剩余81页未读，继续阅读

licyh

粉丝: 3
资源: 64

深入解析Linux内核2.4：启动、进程与中断管理

linux-2.4.37.4

Linux Kernel Internals.pdf

Linux-2.4.0操作系统内核

linux内核源码注解的书

understanding linux network internals pdf

Linux 4.19相关的参考书

linux内核有哪些参考书籍

如何学习linux内核网络

有关liunx的英文参考文献

linux串口编程相关资料。

推荐学习驱动开发的资源

ModuleNotFoundError: No module named 'cartopy.internals'

unix internals pdf

module 'nltk' has no attribute 'internals'

chrome://webrtc-internals 怎么打开

windows internals 7th part2

windows internals 7th

操作系统安全相关参考文献

chrome://webrtc-internals/是什么

运行wpf窗体后点击button按钮显示"未加载System.ServiceModel.Internals.pdb"是什么原因

最新资源