深入内核：ARMv7-M上的Linux调度魔法与PendSV的“延迟艺术”
@[toc] 深入内核：ARMv7-M上的Linux调度魔法与PendSV的“延迟艺术” 当我们将强大的Linux内核移植到资源受限的微控制器（MCU）上，比如基于ARM Cortex-M7的STM32H7时，一个有趣的问题便产生了：这个为拥有MMU、多核心的复杂应用处理器设计的庞然大物，是如何“屈尊”适应一个没有MMU、单核心的MCU环境的？ 答案隐藏在内核最底层的汇编代码中。通过探索其调度逻辑和PendSV的触发机制，我们不仅能理解Linux的惊人适应性，更能领略到不同操作系统在同一硬件架构下，因设计哲学的差异而产生的不同实现路径。 本文将基于对Linux内核ARMv7-M架构底层代码的分析，带你走过一场从中断发生到任务切换的完整旅程，并将其与经典的RTOS设计进行对比。 两种哲学：RTOS与Linux的调度模型在深入代码之前，我们必须先理解两种操作系统在调度上的核心差异。 1. 经典RTOS的调度模型：决策与执行的彻底分离在像RT-Thread这样的经典实时操作系统（RTOS）中，调度过程被清晰地分为两步： 决策（在调度器中）：调度器（如rt_schedule()）...
如何将Git仓库中的特定文件夹及其历史完整迁移到另一个仓库
@[toc] 实战指南：如何将Git仓库中的特定文件夹及其历史完整迁移到另一个仓库在软件项目的演进过程中，我们经常会遇到需要重构代码库的场景。一个常见的需求是：将一个庞大的单体仓库（Monorepo）中的某个模块或组件拆分出来，或者将一个项目中的公共部分提取到一个共享库中。这个过程中，最大的挑战莫过于如何在迁移文件的同时，完整地保留其宝贵的 Git 提交历史。 本文将通过一个真实场景，一步步教你如何使用 git filter-repo 和 git subtree 等强大工具，安全、高效地完成这一任务。 场景设定假设我们有两个本地仓库： 源仓库 (Source)：位于 E:\CODE\fork，这是一个功能复杂的项目。 目标仓库 (Destination)：位于 E:\CODE\test，我们希望将源仓库的一部分功能迁移到这里。 我们的目标是：从源仓库中，只提取 axis 和 UserSrc 这两个文件夹，并将它们相关的、完整的 Git 历史记录，合并到目标仓库中。 第一步：筛选和剥离历史（使用 git filter-repo）要从源仓库中精确地“剥离”出我们想要的文件夹历史...
修复 Git 仓库损坏全记录
@[toc] 实战教程：从”对象文件为空”到仓库重生——修复 Git 仓库损坏全记录当你投入于项目中，执行一个再普通不过的 git add . 命令时，却被一连串鲜红的 fatal: loose object ... is corrupt 错误迎面痛击，这足以让任何开发者心头一紧。这标志着你的本地 Git 仓库的心脏——对象数据库——已经受损。 幸运的是，这通常是可修复的。本文将通过一个真实的修复案例，一步步带你走过诊断、清理、修复和恢复的全过程，让你在面对这类问题时不再束手无策。 案发现场：一个严重损坏的仓库故事始于一个开发者，我们称他为 Alex。Alex 在他的项目 ultra-codetrack 中准备提交代码时，遇到了问题。 1. 初步诊断：错误频发 Alex 首先尝试暂存文件，但立刻收到了错误： 123user@ubuntu:~/projects/ultra-codetrack$ git add .error: 对象文件 .git/objects/37/a2045bc05ca87e84259787c4b118ea3e638c67 为空fatal: 松散对象 37...
将 Git 仓库所有文件移入子目录的正确姿势
@[toc] 从错误到精通：将 Git 仓库所有文件移入子目录的正确姿势1git mv (git ls-tree --name-only HEAD | Where-Object { $_ -ne 'light' }) .\light 在软件项目的生命周期中，重构是常有的事。一个常见的重构任务便是将项目根目录下的所有文件和文件夹移动到一个新的子目录中，例如 src、source 或 app。这个操作看似简单，但在 Git 中，如果想完美地保留所有文件的提交历史，就需要一点技巧。 本文将记录一次完整的探索过程，从最初的错误尝试，到分析问题根源，最终找到在 PowerShell 和 BAT 脚本中都行之有效的、能够保留 Git 历史的完美解决方案。 起始点：一个常见但错误的想法任何一个熟悉命令行的人，第一反应可能都是使用通配符 *： 123# 错误的做法!mkdir new_foldergit mv * new_folder/ 这很快就会失败，并提示一个类似“不能将目录移动到自身子目录中”的错误。原因是 Shell (命令行) 会将 ...
C++ `virtual` 关键字的沉思：为何“万物皆虚”是反模式？
@[toc] C++ virtual 关键字的沉思：为何“万物皆虚”是反模式？ 引言在 C++ 的面向对象编程实践中，virtual 关键字是实现多态性的基石。它允许我们通过基类指针或引用调用派生类的重写函数，是构建灵活、可扩展系统的利器。然而，一个诱人的问题常常浮现在开发者，尤其是单元测试实践者的脑海中：既然虚函数如此强大，且能让依赖模拟（Mocking）变得简单，我们何不将所有成员函数都声明为 virtual 呢？ 这是一个触及 C++ 设计哲学核心的问题。简单的回答是：不，绝对不要这样做。 将所有成员函数声明为 virtual 是一种典型的反模式（anti-pattern），它所带来的问题远比它试图解决的要多。本文将深入剖析其弊端，并阐述使用 virtual 的正确时机与设计原则。 一、 “万物皆虚”的沉重代价将所有函数设为虚函数，会从性能、设计意图和编译器优化三个维度对你的软件产生负面影响。 1.1 性能开销 (Performance Overhead)将函数声明为 virtual 并非没有成本。这种成本体现在内存和运行时两个方面。 内存开销: 每个包含至少一个虚函...
解决因取消VMware快照删除导致的虚拟机磁盘损坏问题
@[toc] 解决因取消VMware快照删除导致的虚拟机磁盘损坏问题在使用VMware虚拟机时，快照是一个非常方便的功能，但操作不当也可能引发严重问题。本文将分享一个真实案例：在删除虚拟机快照时点击“取消”按钮，导致虚拟机磁盘损坏无法启动，并提供详细的解决方案。 问题描述您是否遇到过这样的情况：在VMware Workstation中为一台虚拟机（下称“My-VM”）删除快照，由于过程耗时较长，您选择点击了“取消”按钮。此后，这台虚拟机便无法正常开机，并提示“打不开此虚拟机的父磁盘”。 如果您尝试进入虚拟机设置，对该磁盘进行压缩或整理，系统会弹出错误：“指定的虚拟磁盘需要进行修复”。 分析问题根源：日志文件中的线索遇到这类问题时，第一步应该是查看虚拟机的日志文件（vmware.log），它通常位于虚拟机文件所在的目录。日志中记录了虚拟机运行的详细过程和错误信息，是诊断问题的关键。 在本次案例的日志文件中，可以找到以下关键错误信息： 1234562025-08-14T06:42:43.645Z Er(02) worker-19544 DISKLIB-LINK : DiskL...
必应搜索错乱：当搜索结果与输入不符时，你该怎么办
[toc] 必应搜索错乱：当搜索结果与输入不符时，你该怎么办？在日常生活中，搜索引擎已成为我们获取信息不可或缺的工具。然而，你是否曾遇到这样的情况：在必应（Bing）中输入了一个清晰的搜索词，却得到了南辕北辙的结果？这无疑会让人感到困惑和沮丧。本文将深入探讨必应搜索结果错乱的常见原因，并提供详细的解决方法，助你更高效地驾驭信息海洋。 一、 🔍 问题浮现：搜索结果为何“跑偏”？想象一下，你只想搜索“最新的智能手机评测”，结果却跳出了关于“智慧城市规划”的文章，这便是典型的搜索结果与输入不符。这种“跑偏”并非偶然，背后往往隐藏着多种原因。 常见原因一：输入细节决定成败 拼写错误与错别字： 这是最常见也是最容易被忽视的原因。一个字母之差，可能让搜索引擎完全“会错意”。 同音异义词与多义词： 某些词语发音相同但意义不同，或一个词语本身就有多种含义。例如，“苹果”既可以是水果，也可以是科技公司。 过于模糊或口语化的表达： 搜索引擎更擅长处理结构化和明确的关键词。过于口语化或不明确的短语可能让它难以精准理解你的意图。 常见原因二：搜索引擎的“思考方式” 算法理解偏差： 搜索引擎...
Linux 内核 `jiffies` 更新机制解析：周期性Tick模型和动态时钟
@[toc] Linux 内核 jiffies 更新机制解析：周期性Tick模型和动态时钟/无Tick模型的实现与行为 1. jiffies 更新的双重模型框架Linux内核对jiffies全局计数器的更新并非采用单一策略，而是根据中央处理器（CPU）的运行状态和系统配置，在两种截然不同的模型间进行切换。 1.1 周期性Tick模型 (Periodic Tick Model) 适用条件：此模型在CPU持续执行非空闲任务，或内核未完全开启CONFIG_NO_HZ_FULL等动态时钟配置时被激活。 工作机制：内核中存在一个周期性的时钟中断事件。该中断以一个由内核编译时配置的HZ值所决定的固定频率（例如250Hz）规律性地发生。在现代内核中，此中断通常由高精度定时器（hrtimer）模拟的tick_sched_timer来驱动。 jiffies更新行为：在每一次时钟中断的服务例程中，tick_periodic()函数都将被调用，其核心任务之一就是将全局变量jiffies_64的值原子性地增加1。在此模型下，jiffies的增长是线性的、可预测的。 其更新流程如下图所示：...
Linux 内核 `kthread_stop` 完成量等待是如何被唤醒
@[toc] Linux 内核 kthread_stop 完成量等待是如何被唤醒 引言在Linux内核编程中，kthread_stop 是一个用于请求并同步等待内核线程（kthread）退出的标准函数。其接口定义清晰，但其内部的同步机制横跨了调度、内存管理和进程退出的多个核心子系统。调用 kthread_stop 的线程会因 wait_for_completion 调用而阻塞，直至目标线程彻底退出。本文旨在精确剖析并阐述 kthread_stop 的同步唤醒机制，揭示其依赖于对 task_struct->vfork_done 字段的重用，并通过标准的 mm_release 路径触发唤醒信号的实现细节。 一、 机制基础：set_kthread_struct 函数中的指针重用理解 kthread_stop 唤醒路径的前提，是对内核线程创建时的数据结构初始化进行分析。在线程创建过程中，set_kthread_struct 函数负责关联 task_struct 与 kthread 私有结构体，并在此过程中建立了一个决定性的链接。 set_kthread_struct 源码解析1...
Linux 内核中断与时间子系统深度解析：从硬件到`jiffies`的完整生命周期
@[toc] Linux 内核中断与时间子系统深度解析：从硬件到jiffies的完整生命周期 1. 引言Linux内核的稳定运行，高度依赖于其底层两大基石——中断处理框架与时间管理子系统。中断框架负责响应来自硬件的异步事件，而时间管理子系统则为整个内核提供统一的时间基准——jiffies全局节拍计数器。这两大系统并非独立运行，而是通过一套设计精良、层次分明的接口进行精密协作。在某些配置模式下，jiffies的每一次递增，都源于一个硬件定时器产生的物理中断。 本文旨在对这一协作过程进行一次完整的、端到端的深度剖析。我们将首先详细阐述jiffies的双重更新模型，然后分别深入其在动态时钟（NOHZ）和高精度定时器驱动下的实现路径。随后，文章将回溯到传统的低精度模式，分析硬件定时器如何被注册为系统节拍源，并追踪一个硬件中断从发生到最终触发通用tick处理的完整流程。最后，我们将对内核中断处理的完整生命周期进行梳理，揭示其从静态初始化到运行时触发的精妙设计。 2. jiffies 的双重更新模型Linux内核对jiffies的更新并非采用单一策略，而是根据CPU的运行状态和系统配置，...
