wdfk-prog的个人博客

@[toc] https://github.com/wdfk-prog/linux-study 前言 之所以写这个文章,是因为阅读linux源码时被坑了.直接F12跳转到了其他地方.分析了半天都看不明白.晕头转向的.跳回来在分析了一遍才发现有个坑的地方.特除记录说明. lib/decompress_inflate.c 这里的__gunzip函数需要进行malloc.如果直接用F12进行跳转到函数声明与定义的地方,大概率是跳转到include/linux/decompress/mm.h 123456/* Use defines rather than static inline in order to avoid spurious * warnings when not needed (indeed large_malloc / large_free are not * needed by inflate */#define malloc(a) kmalloc(a, GFP_KERNEL)#define free(a) kfree(a) 实际上这里还未进...

@[toc] https://github.com/wdfk-prog/linux/tree/ART-PI_DEBUG DEBUG_LL的功能 开启早期的调试功能 12345678910111213# These options are only for real kernel hackers who want to get their hands dirty.config DEBUG_LL bool "Kernel low-level debugging functions (read help!)" depends on DEBUG_KERNEL help Say Y here to include definitions of printascii, printch, printhex in the kernel. This is helpful if you are debugging code that executes before the console is initialized. Note that select...

@[toc] https://people.kernel.org/monsieuricon/sending-a-kernel-patch-with-b4-part-1 1. 使用pip安装1234$ pip install --user b4[...]$ b4 --version0.11.1 2. 使用b4切换分支1b4 prep -n [name-of-branch] -f [nearest-tag] 例如:b4 prep -n __reserved_mem_init_node v6.15-rc2,最好使用-f固定tag版本 3. b4 prep --edit-cover 将自己的补丁信息描述清楚并提交 可以参考修改的文件的其他pr的描述格式进行提交 例如 123456789101112131415of: reserved-mem: Warn for missing initfn in __reservedmem_of_tableFor the data in __reservedmem_of_table, its function pointer initfn ...

@[toc] 问题背景分析在Linux环境下开发STM32H7系列芯片时，发现系统时钟sys_ck的时钟源并非手册标明的默认HSI（High Speed Internal oscillator），而是被配置为PLL1。这种现象需要从系统启动流程的底层进行分析。 关键发现通过追踪系统启动流程，发现u-boot引导阶段已经对时钟进行了重新配置。在u-boot的时钟驱动代码中明确设置了PLL1作为系统时钟源： 1234/* 选择PLL1作为系统时钟源(sys_ck) */clrsetbits_le32(&regs->cfgr, RCC_CFGR_SW_MASK, RCC_CFGR_SW_PLL1);while ((readl(&regs->cfgr) & RCC_CFGR_SW_MASK) != RCC_CFGR_SW_PLL1) ; 这段代码位于drivers/clk/stm32/clk-stm32h7.c文件的configure_clocks函数中，执行以下操作： 清除RCC_CFGR寄存器中的时钟源选择位 设置PLL1作为新的系统...

@[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()）...

@[toc] 内核“创世纪”：新任务的第一次呼吸是如何伪造的？ 在多任务操作系统中，我们想当然地认为任务切换就是“保存旧任务的状态，恢复新任务的状态”。但一个悖论随之而来：如果一个任务是全新创建的，它从未运行过，自然也就没有一个“旧状态”可供恢复。那么，当调度器第一次选中这个新任务时，CPU的PC指针该跳向何方？SP栈指针又该指向哪里？ 答案是：伪造。 内核在创建新任务时，会扮演一名技艺高超的“现场伪造专家”，在任务的内核栈上，手动地、精确地构建一个假的上下文现场。这个假现场看起来就像是这个任务在某个神秘的、预设好的点被正常“切换”出去一样。 本文将带您深入Linux内核的fork过程，揭开新任务“第一次呼吸”背后那令人惊叹的伪造艺术。 创生之地：copy_thread函数当我们在用户空间调用fork()或在内核中创建新线程时，内核最终都会调用一个名为copy_process()的函数。在这个函数中，所有与进程相关的资源被复制。而最核心的、与CPU状态相关的初始化，则发生在copy_thread()这个特定于体系结构的函数中。 copy_thread的使命，就是在新任务（p...

@[toc] C++ virtual 关键字的沉思：为何“万物皆虚”是反模式？ 引言在 C++ 的面向对象编程实践中，virtual 关键字是实现多态性的基石。它允许我们通过基类指针或引用调用派生类的重写函数，是构建灵活、可扩展系统的利器。然而，一个诱人的问题常常浮现在开发者，尤其是单元测试实践者的脑海中：既然虚函数如此强大，且能让依赖模拟（Mocking）变得简单，我们何不将所有成员函数都声明为 virtual 呢？ 这是一个触及 C++ 设计哲学核心的问题。简单的回答是：不，绝对不要这样做。 将所有成员函数声明为 virtual 是一种典型的反模式（anti-pattern），它所带来的问题远比它试图解决的要多。本文将深入剖析其弊端，并阐述使用 virtual 的正确时机与设计原则。 一、 “万物皆虚”的沉重代价将所有函数设为虚函数，会从性能、设计意图和编译器优化三个维度对你的软件产生负面影响。 1.1 性能开销 (Performance Overhead)将函数声明为 virtual 并非没有成本。这种成本体现在内存和运行时两个方面。 内存开销: 每个包含至少一个虚函...

[toc] 必应搜索错乱：当搜索结果与输入不符时，你该怎么办？在日常生活中，搜索引擎已成为我们获取信息不可或缺的工具。然而，你是否曾遇到这样的情况：在必应（Bing）中输入了一个清晰的搜索词，却得到了南辕北辙的结果？这无疑会让人感到困惑和沮丧。本文将深入探讨必应搜索结果错乱的常见原因，并提供详细的解决方法，助你更高效地驾驭信息海洋。 一、 🔍 问题浮现：搜索结果为何“跑偏”？想象一下，你只想搜索“最新的智能手机评测”，结果却跳出了关于“智慧城市规划”的文章，这便是典型的搜索结果与输入不符。这种“跑偏”并非偶然，背后往往隐藏着多种原因。 常见原因一：输入细节决定成败 拼写错误与错别字： 这是最常见也是最容易被忽视的原因。一个字母之差，可能让搜索引擎完全“会错意”。 同音异义词与多义词： 某些词语发音相同但意义不同，或一个词语本身就有多种含义。例如，“苹果”既可以是水果，也可以是科技公司。 过于模糊或口语化的表达： 搜索引擎更擅长处理结构化和明确的关键词。过于口语化或不明确的短语可能让它难以精准理解你的意图。 常见原因二：搜索引擎的“思考方式” 算法理解偏差： 搜索引擎...

@[toc] 解决因取消VMware快照删除导致的虚拟机磁盘损坏问题在使用VMware虚拟机时，快照是一个非常方便的功能，但操作不当也可能引发严重问题。本文将分享一个真实案例：在删除虚拟机快照时点击“取消”按钮，导致虚拟机磁盘损坏无法启动，并提供详细的解决方案。 问题描述您是否遇到过这样的情况：在VMware Workstation中为一台虚拟机（下称“My-VM”）删除快照，由于过程耗时较长，您选择点击了“取消”按钮。此后，这台虚拟机便无法正常开机，并提示“打不开此虚拟机的父磁盘”。 如果您尝试进入虚拟机设置，对该磁盘进行压缩或整理，系统会弹出错误：“指定的虚拟磁盘需要进行修复”。 分析问题根源：日志文件中的线索遇到这类问题时，第一步应该是查看虚拟机的日志文件（vmware.log），它通常位于虚拟机文件所在的目录。日志中记录了虚拟机运行的详细过程和错误信息，是诊断问题的关键。 在本次案例的日志文件中，可以找到以下关键错误信息： 1234562025-08-14T06:42:43.645Z Er(02) worker-19544 DISKLIB-LINK : DiskL...

@[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...