wdfk-prog的个人博客

[toc] kernel/sched/syscalls.c 调度相关的系统调用(Scheduler-Related System Calls) 用户空间与调度器交互的接口历史与背景这项技术是为了解决什么特定问题而诞生的？kernel/sched/syscalls.c 这个文件本身并不是一种“技术”，而是用户空间与内核调度器进行交互的官方API层。它的存在是为了解决一个至关重要的问题：如何为一个用户空间的应用程序提供一个稳定、受控且安全的接口，使其能够查询或影响自身以及其他进程的调度行为。 内核调度器（fair.c, rt.c, deadline.c等）是一个极其复杂的内部子系统。如果没有syscalls.c这一层“防火墙”和“翻译官”，就会出现以下问题： 缺乏控制：用户程序将无法请求更高的执行优先级（如实时音频应用）、降低后台任务的影响（如批处理任务），或将任务绑定到特定的CPU核心以优化性能。 安全漏洞：任何程序都可以随意修改系统上所有进程的优先级，一个普通用户进程就能通过提升自己为最高优先级的实时任务来饿死所有其他进程，导致系统完全锁死。 缺乏抽象：应用...

[TOC] kernel/sched 调度器核心(Scheduler Core) 进程调度与上下文切换的决策中心历史与背景这项技术是为了解决什么特定问题而诞生的？kernel/sched/core.c 及其关联文件（如fair.c, rt.c）共同构成了Linux内核的进程调度器（Process Scheduler）。这项技术是为了解决在分时多任务操作系统中一个最根本、最核心的问题：在多个可运行的进程（或线程）之间，如何以及何时分配有限的CPU时间，以达到系统设定的目标。 这些目标通常是相互冲突的，调度器的设计就是在它们之间做出权衡和取舍： 公平性（Fairness）：确保每个普通进程都能获得合理的CPU时间份额，防止任何进程被“饿死”。 吞吐量（Throughput）：最大化系统在单位时间内完成的总工作量。这通常有利于长时间运行的计算密集型任务。 响应性（Responsiveness）：最小化交互式任务（如GUI应用、文本编辑器）的响应延迟，让用户感觉系统“流畅”。这要求任务能被快速唤醒并执行。 实时性（Real-time）：确保需要满足严格截止时间（deadlin...

[TOC] include/linux/preempt.h 内核抢占(Kernel Preemption) 控制内核代码的可抢占性与延迟历史与背景这项技术是为了解决什么特定问题而诞生的？include/linux/preempt.h 是定义**内核抢占（Kernel Preemption）相关API和配置的头文件。这项技术的诞生是为了解决早期Linux内核的一个核心设计局限性：内核态执行的不可抢占性（non-preemptibility），以及由此导致的系统响应延迟（latency）**问题。 在Linux 2.6版本之前，内核是非抢占式的。这意味着，当一个进程通过系统调用进入内核态执行时，它会一直占有CPU，直到它自愿放弃（例如，因等待I/O而睡眠）或执行完毕返回用户空间。这种模型的缺点是： 高延迟：如果一个低优先级的进程执行了一个非常耗时的系统调用（例如，对一个大文件进行复杂的读写），那么一个刚刚被唤醒的、需要立即响应用户输入的高优先级进程（如桌面窗口管理器或文本编辑器）将不得不一直等待，直到那个系统调用完成。这会导致系统UI卡顿，响应迟钝。 ...

[toc] kernel/sched/rt.c 实时调度(Real-Time Scheduling) 保证关键任务的优先执行历史与背景这项技术是为了解决什么特定问题而诞生的？kernel/sched/rt.c 是Linux内核实时调度器的核心实现。它的诞生不是为了“公平”或“高吞吐量”，而是为了解决一个截然不同的、至关重要的问题：可预测的时间行为（Predictable Temporal Behavior）。 在通用计算中（由CFS调度器处理），一个任务晚几毫秒完成通常无伤大雅。但在很多领域，任务的正确性不仅取决于计算结果，更取决于结果产生的时间。如果一个任务错过了它的截止时间（deadline），即使结果正确，也可能造成灾难性后果。这些场景包括： 工业控制：机器人手臂的控制指令必须在几毫秒内发出，否则可能导致生产事故。 电信基础设施：处理5G网络数据包的设备，必须在严格的时间窗内完成，以保证通信质量。 专业音视频处理：音频处理线程必须周期性地、准时地向声卡提供数据，否则就会出现爆音（xrun）。 金融交易：高频交易算法的执行延迟直接关系到经济效益。 ke...

[toc] kernel/rcu/srcu.c Sleepable Read-Copy Update (SRCU) 允许睡眠的RCU变体历史与背景这项技术是为了解决什么特定问题而诞生的？Sleepable Read-Copy Update (SRCU) 的诞生是为了解决标准RCU（包括Classic RCU和Preemptible RCU）的一个核心限制：其读侧临界区（read-side critical section）内不允许睡眠。 标准的RCU通过监控CPU的静止状态（如上下文切换、进入idle）来确定宽限期（Grace Period），而这些监控手段都假设了读者在持有“锁”（即在rcu_read_lock()和rcu_read_unlock()之间）时不会主动放弃CPU（即睡眠）。 然而，在内核中存在很多场景，开发者需要在访问一个被RCU保护的、读多写少的数据结构的同时，执行一些可能会导致睡眠的操作。例如： 与用户空间交互：调用 copy_from_user() 或 copy_to_user()，这些函数在访问的用户内存被换出到磁盘时，会发生页错误并...

[TOC] kernel/rcu Read-Copy Update (RCU) 高性能的内核同步机制历史与背景这项技术是为了解决什么特定问题而诞生的？Read-Copy Update (RCU) 技术的诞生，是为了解决在多核处理器系统中，对**读多写少（Read-mostly）**类型共享数据进行同步时遇到的性能瓶颈问题。 传统的同步机制，如读写锁（Reader-Writer Locks），虽然允许多个读者同时访问数据，但存在以下问题： 读者开销：即使是读取操作，读者也必须获取一个锁（或至少执行原子操作来增加引用计数）。在多核环境下，这会导致缓存行在CPU之间频繁“弹跳”（cache line bouncing），造成严重的性能下降和扩展性问题。 锁争用：当写者需要获取锁时，它可能会被已有的读者阻塞，或者需要等待新的读者完成。反之，写者持有锁时，所有读者都必须等待。这种争用在高并发读取场景下尤为突出。 RCU 的核心目标就是让读者几乎零开销（wait-free）。它允许读者在访问数据时完全不需要获取任何锁、自旋锁或执行原子指令，从而消除了读者端的同步开销和扩展性瓶颈...

容器设备(Container Device) 聚合与管理SoC内嵌设备drivers/base/container.c 是Linux内核设备模型中的一个辅助性组件。它的核心功能是提供一个标准的机制，用于将一组逻辑上相关、但不一定在同一物理总线上的设备，聚合到一个统一的“容器设备”之下。这种机制最主要的应用场景是为复杂的片上系统（SoC）创建一个顶层设备节点，从而将构成该SoC的所有独立功能块（如I2C控制器、DMA引擎等）组织成一个清晰的层次结构。 历史与背景这项技术是为了解决什么特定问题而诞生的？ 随着嵌入式系统的发展，现代SoC集成了越来越多的功能单元。在Linux设备模型中，这些单元通常被表示为独立的平台设备（platform_device）。这导致了一个问题： 缺乏层次结构：在sysfs的设备树（/sys/devices）中，一个SoC上的所有平台设备可能都以扁平的方式挂载在 platform 总线下，无法直观地体现出它们都属于同一个物理芯片。 管理困难：当需要对整个SoC进行统一操作时（例如，作为一个整体进行电源管理或状态查询），缺乏一个代表SoC本身的顶层设备节点，...

[toc] kernel/rcu/tree.c Tree RCU - 应对大规模多核系统的RCU扩展性实现历史与背景这项技術是爲了解决什么特定问题而诞生的？kernel/rcu/tree.c 并不是一种新的RCU“类型”（像SRCU那样），而是标准RCU（包括Preemptible RCU）的一种高性能、高可扩展性的实现方式。它的诞生是为了解决随着多核处理器（SMP）系统中CPU核心数量急剧增加，最初的“扁平化”RCU实现所面临的严重扩展性瓶颈问题。 RCU的核心是等待一个“宽限期”（Grace Period）结束，而宽限期的结束依赖于确认系统中所有CPU都已经经历过至少一次静止状态（Quiescent State）。在早期的、核心数较少的系统中，RCU协调器可以通过检查一个全局的数据结构来轮询或追踪每个CPU的状态。 然而，当CPU核心数从个位数增长到几十、几百甚至上千时，这种“扁平化”的管理方式导致了： 全局锁/数据争用：所有CPU都需要向一个中心点报告自己的状态，或者由一个中心任务去检查所有CPU的状态。这会导致对同一个全局锁或缓存行的激烈争...

[TOC] drivers/base/cpu.c CPU设备管理(CPU Device Management) CPU热插拔的核心实现drivers/base/cpu.c 是Linux内核设备模型中的一个基础文件，其核心职责是将系统中的各个CPU（中央处理器）抽象为标准的设备，并通过sysfs文件系统进行管理。该文件最主要的功能是为Linux内核提供CPU热插拔（CPU Hotplug）机制的通用框架，允许在系统运行时动态地使CPU核心上线（online）或离线（offline）。 历史与背景这项技术是为了解决什么特定问题而诞生的？CPU热插拔机制的出现主要是为了满足日益复杂的系统需求： RAS（可靠性、可用性、可服务性）：在高端服务器和NUMA（非统一内存访问）硬件中，系统需要能够在不宕机的情况下，物理上移除发生故障的CPU节点，或添加新的计算资源。 电源管理：在负载较低时，可以将闲置的CPU核心完全离线，从而彻底切断其电源，实现比普通待机模式更深层次的节能。 资源灵活性与虚拟化：在虚拟化环境中，可以根据虚拟机的负载动态增加或减少vCPU（虚拟CPU）的数...

[TOC] drivers/base/devtmpfs.chandle_create 创建一个设备节点（device node）123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141// 在内核空间创建一个目录。// name: 要创建的目录的路径字符串。// mode: 目录的访问权限模式 (例如 0755)。static int dev_mkdir(const char *name, umo...