使用Boost.Context模块进行callcc的throw测试

最新推荐文章于 2025-02-24 11:08:48 发布
最新推荐文章于 2025-02-24 11:08:48 发布
阅读量112 收藏 1
点赞数 1
CC 4.0 BY-SA版权
文章标签： c++ 算法 开发语言 编程
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/DevWizard/article/details/132681043
编程 专栏收录该内容
410 篇文章 ¥29.90 ¥99.00
订阅专栏
本文介绍如何利用Boost.Context库进行callcc的throw测试。通过一个示例展示了在协程中抛出并捕获异常的过程，强调了Boost.Context在控制流转移和异常处理上的应用。

使用Boost.Context模块进行callcc的throw测试

Boost.Context是一个C++库，提供了协程（coroutine）和生成器（generator）的实现。其中的callcc（call-with-current-continuation）函数允许在协程之间进行控制流转移。在本篇文章中，我们将使用Boost.Context模块来进行callcc的throw测试。

在开始编写测试程序之前，我们需要确保已经正确安装了Boost库，并且已经配置好了编译环境。接下来，我们将展示一个简单的示例来演示如何使用Boost.Context模块进行callcc的throw测试。

#include <iostream>
#include <boost/context/all.hpp>

typedef boost
了解本专栏 订阅专栏 解锁全文
Boost::context模块callcc函数的使用
AlianBlank的博客
08-22 229
在 child_fn1 中，我们调用了 jump_fcontext 函数将当前协程切换到 fctx2 对应的协程执行，并在其中打印了一条输出信息。随后，在 child_fn2 函数中，我们再次调用 jump_fcontext 函数将当前协程切换回 fctx1 对应的协程执行，并在其中也打印了一条输出信息。其中，最常用的函数是 callcc 函数，它允许我们将当前协程保存到一个上下文对象中，并切换到另一个协程执行。当后续需要重新执行原先的协程时，我们可以通过该上下文对象恢复之前的状态，继续执行。
Boost.context模块的callcc解析器测试程序
TechPr的博客
08-17 140
本文将介绍如何使用Boost.context模块的callcc机制，并提供一个简单的解析器测试程序。最后，我们又通过使用get_executor()(ctx1)函数，将控制权切换回到ctx1上下文。在parse()函数中，我们可以通过get_executor()(ctx)函数，将控制权再次传递给lambda表达式。Boost.context的callcc机制提供了一种不同的控制流解决方案，它允许我们在协程之间传递控制权。由于使用了协程，这个解析器实现了非常简洁的代码，同时也能够灵活的处理控制权。
boost-context-1.66.0-10.el8.i686.rpm
12-04
离线安装包，亲测可用
boost context上下文切换
Erick Lv的笔记
07-19 4476
上下文简介 首先要理解boost::context的概念和应用场景。程序在执行的时候，当前的执行的代码环境和所处的状态，就是context。boost::context保留了当前程序执行时的寄存器等的状态，可以认为是一个上下文A；然后线程就可以去执行其他的代码，完成执行后，可以切回上下文A，并从当初切走的地方执行，而且当初的上下文的现场不变，这就是完成了一次真正意义上的上下文切换。 上线文切换，在协程和用户态线程等有重要的意义（统称它们为routine），我们可以启动一定数量的操作系统的线程，然后让rout
argobots && boost.fcontext（一）
vggggv的博客
01-10 1107
argobots协程底层实现
Context 终于进 boost 了
whinah的专栏
09-04 5642
Version 1.51.0 New Libraries: Context Boost.Context is a foundational library that provides a sort of cooperative multitasking on a single thread. By providing an abstraction of the current exe
使用Boost.Context模块进行callcc的回声测试程序
DevPulse的博客
09-04 138
通过这个示例程序，我们可以了解到Boost.Context模块的基本使用方法，以及如何使用callcc函数进行协程之间的控制流切换。其中的callcc函数是Boost.Context模块的一个重要特性，它允许在协程之间进行控制流的切换。接下来，我们将给出一个简单的示例程序，展示如何使用Boost.Context的callcc函数实现回声测试。通过这个简单的示例程序，我们可以看到Boost.Context模块的callcc函数是如何实现协程之间的切换和控制流的传递的。函数，从而触发了协程的执行。
使用Boost.Context模块进行callcc的jump测试程序
CyberByte的博客
09-09 148
其中，callcc函数是该库中的一个重要特性，它允许我们在协程之间进行跳转，从而实现非局部的控制流程转移。通过这个简单的例子，我们可以看到Boost.Context的callcc函数提供了一种在不同协程之间进行控制流转移的灵活机制。接下来，我们将编写一个简单的测试程序，以便演示如何使用Boost.Context的callcc函数进行跳转。函数创建了一个协程上下文，其中第一个参数为协程的栈大小，默认使用系统默认大小，第二个参数为协程的入口函数。函数中，我们首先输出"Entering main"，表示进入了。
使用Boost.Context模块的callcc进行无限循环的测试程序
HackMasterX的博客
09-14 73
在本文中，我们将介绍如何使用Boost.Context模块的callcc函数来实现一个无限循环的测试程序。总结起来，本文介绍了如何使用Boost.Context模块的callcc函数来实现一个无限循环的测试程序。通过使用该函数，我们可以方便地创建和切换协程，从而控制程序的执行流程。这证明我们成功地使用Boost.Context模块的callcc函数创建并执行了一个无限循环的协程。这样，我们就创建了一个无限循环的协程，并通过上下文切换来控制程序的执行流程。在上面的代码中，我们定义了一个函数。
Boost.Asio 的核心：执行器（Executor）与上下文（Context）
arrow8209的专栏
02-24 647
Boost.Asio 的核心：执行器（Executor）与上下文（Context）
cpp-C14高性能非阻塞网络IO基于epollboostcontext
08-16
C 14高性能非阻塞网络IO（基于epoll boost.context）
Boost.Context 模块中的 `callcc` 函数与 `jump` 和 `mov` 的测试程序
2301_79331421的博客
09-06 110
从输出结果可以看出，程序先执行了主循环，然后创建了协程并执行了协程的代码。在协程执行过程中，我们可以看到协程和主循环交替执行，直到协程执行结束，然后主循环继续执行直至退出。在该函数内部，我们使用一个循环来模拟协程的执行过程，并在每次循环迭代时输出一些信息。接下来，我们使用一个循环来模拟主循环的执行过程，并在每次迭代时输出一些信息。通过使用这些函数，我们可以方便地创建和控制协程的执行过程，实现协程的切换和调度。表达式来暂停当前的主循环，并将控制权返回给协程。来恢复协程的执行，直到协程执行完毕。
Boost::context模块callcc的jump测试程序
希望我的博客，能帮上你解决学习中工作中所遇到的问题
05-25 462
Boost::context模块callcc的jump测试程序实现功能C++实现代码 实现功能 Boost的context模块，Boost::context模块callcc的jump测试程序 C++实现代码 #include <cstdlib> #include <iostream> #include <boost/context/continuation.hpp> namespace ctx = boost::context; int main() { ctx:
Boost::context模块fiber的stack测试程序
希望我的博客，能帮上你解决学习中工作中所遇到的问题
05-25 452
Boost::context模块fiber的stack测试程序实现功能C++实现代码 实现功能 Boost::context模块fiber的stack测试程序 C++实现代码 #include <cstdlib> #include <iostream> #include <boost/context/continuation.hpp> namespace ctx = boost::context; int main() { std::cout << "
使用Boost.Context模块进行jump_void测试的程序
2301_79325657的博客
09-07 102
其中的callcc函数（Continuation Passing Style）是一种特殊的控制流机制，允许程序在任意位置保存当前的执行状态，并在之后的任意位置恢复执行。通过以上的例子，我们演示了如何使用Boost.Context模块的callcc函数进行jump_void测试。恢复了之前保存的执行状态，并继续执行之前被中断的地方，输出了"Back to jump_func"。最后，程序回到了主函数中，输出了"Back in main"。会恢复之前保存的执行状态，继续执行之前被中断的地方。
Boost::context模块callcc的斐波那契测试程序
希望我的博客，能帮上你解决学习中工作中所遇到的问题
05-25 454
Boost::context模块callcc的斐波那契测试程序实现功能C++实现代码 实现功能 Boost的context模块，Boost::context模块callcc的斐波那契测试程序 C++实现代码 #include <cstdlib> #include <iostream> #include <memory> #include <boost/context/continuation.hpp> namespace ctx = boost::contex
Boost::context模块callcc的回溯测试程序
希望我的博客，能帮上你解决学习中工作中所遇到的问题
05-25 555
Boost::context模块callcc的回溯测试程序实现功能C++实现代码 实现功能 Boost的context模块，Boost::context模块callcc的回溯测试程序 C++实现代码 #define UNW_LOCAL_ONLY #include <cstdlib> #include <iostream> #include <libunwind.h> #include <boost/context/continuation.hpp> names
协程分析之context上下文切换
weixin_34311757的博客
10-28 789
为什么80%的码农都做不了架构师？>>> ...
Boost.Context模块纤程的回溯测试程序
DevPulse的博客
08-09 147
在main()函数中，我们首先创建了一个名为“foo”的纤程。在“foo”函数中，我们使用了一个vector对象存储了整数1, 2和3，并使用for循环遍历了这个vector对象。总结一下，本文介绍了如何使用Boost.Context模块来实现纤程的回溯，并提供了一个简单的示例代码。使用Boost库中的协程和纤程可以帮助我们更好地管理程序的执行流程和资源的分配。在输出中，我们可以看到纤程“foo”和主线程交替执行，而且在最后的输出中我们可以看到纤程“foo”在执行完毕后结束了。
现在又Kbuild文件如下TOP := $(srctree)/.. CAMERA_ROOT=$(TOP)/vendor/oplus/kernel/camera ifeq ($(DEVICE_MODULES_PATH),) DEVICE_MODULES_PATH = $(srctree) else LINUXINCLUDE := $(DEVCIE_MODULES_INCLUDE) $(LINUXINCLUDE) endif LINUX_INC += -Iinclude/linux \ -Iinclude/linux/drm \ -Iinclude/linux/gunyah \ -Iinclude/linux/gunyah \ -Iinclude CDEFINES += -DANI_LITTLE_BYTE_ENDIAN \ -DANI_LITTLE_BIT_ENDIAN \ -DDOT11F_LITTLE_ENDIAN_HOST \ -DANI_COMPILER_TYPE_GCC \ -DANI_OS_TYPE_ANDROID=6 \ -DPTT_SOCK_SVC_ENABLE \ -Wall\ -Werror\ -D__linux__ KBUILD_CPPFLAGS += $(CDEFINES) ifneq ($(wildcard $(CAMERA_ROOT)/config/camera.conf),) include $(CAMERA_ROOT)/config/camera.conf LINUX_INC += -include $(CAMERA_ROOT)/config/camera.h endif ccflags-y += $(LINUX_INC) ifeq ($(call cc-option-yn, -Wmaybe-uninitialized),y) EXTRA_CFLAGS += -Wmaybe-uninitialized endif ifeq ($(call cc-option-yn, -Wheader-guard),y) EXTRA_CFLAGS += -Wheader-guard endif obj-m += regulator/ obj-m += lens/ obj-m += flashlight/v4l2/ obj-m += thermal/ 还有如下Makefile # SPDX-License-Identifier: GPL-2.0-only # Copyright (C) 2018-2022 Oplus. All rights reserved. ifneq ($(wildcard $(KERNEL_SRC)/android/abi_gki_aarch64.stg),) BOOT_MIXED_BUILD=true endif KBUILD_OPTIONS+= DFT_ROOT=$(KERNEL_SRC)/$(M) KBUILD_OPTIONS += MODNAME?=dft_dlkm ifneq ($(wildcard $(KERNEL_SRC)/$(DEVICE_MODULES_REL_DIR)/Makefile.include),) include $(KERNEL_SRC)/$(DEVICE_MODULES_REL_DIR)/Makefile.include endif all: EXTRA_SYMBOLS += $(extra_symbols) all: $(MAKE) -C $(KERNEL_SRC) M=$(M) modules $(KBUILD_OPTIONS) KBUILD_EXTRA_SYMBOLS="$(EXTRA_SYMBOLS)" modules_install: $(MAKE) INSTALL_MOD_STRIP=1 -C $(KERNEL_SRC) M=$(M) modules_install %: $(MAKE) -C $(KERNEL_SRC) M=$(M) $@ $(KBUILD_OPTIONS) clean: rm -f *.o *.ko *.mod.c *.mod.o *~ .*.cmd Module.symvers rm -rf .tmp_versions 向我逐行解释这两个文件
最新发布
06-18
<think>我们有两个文件：一个是Kbuild（或Kbuild片段），另一个是Makefile。它们都是用于构建Linux内核模块的。我们将逐行解释这两个文件的内容。###文件1:Kbuild（或构建脚本片段）```makefileTOP:=$(srctree)/..```-`TOP:=$(srctree)/..`：设置变量`TOP`为内核源码树（`srctree`）的上一级目录。通常`srctree`是内核源码的根目录，所以`TOP`就是内核源码根目录的父目录。---```makefileCAMERA_ROOT=$(TOP)/vendor/oplus/kernel/camera```-`CAMERA_ROOT`被设置为`TOP`下的特定路径，指向摄像头相关的内核代码目录。---```makefileifeq($(DEVICE_MODULES_PATH),)DEVICE_MODULES_PATH=$(srctree)elseLINUXINCLUDE:=$(DEVCIE_MODULES_INCLUDE)$(LINUXINCLUDE)endif```-检查`DEVICE_MODULES_PATH`是否为空。-如果为空，则将其设置为内核源码树根目录（`$(srctree)`）。-如果不为空，则将`LINUXINCLUDE`（内核头文件搜索路径）更新为`$(DEVICE_MODULES_INCLUDE)`加上原来的`LINUXINCLUDE`。注意：这里有一个拼写错误`DEVCIE`应该是`DEVICE`。---```makefileLINUX_INC+=-Iinclude/linux\-Iinclude/linux/drm\-Iinclude/linux/gunyah\-Iinclude/linux/gunyah\-Iinclude```-向`LINUX_INC`变量追加多个`-I`标志，用于指定头文件的搜索路径。这些路径是相对于内核源码目录的。注意：`-Iinclude/linux/gunyah`被重复了两次（可能是冗余的）。---```makefileCDEFINES+=-DANI_LITTLE_BYTE_ENDIAN\-DANI_LITTLE_BIT_ENDIAN\-DDOT11F_LITTLE_ENDIAN_HOST\-DANI_COMPILER_TYPE_GCC\-DANI_OS_TYPE_ANDROID=6\-DPTT_SOCK_SVC_ENABLE\-Wall\-Werror\-D__linux__```-向`CDEFINES`变量追加多个预处理器宏定义（`-D`）和编译选项（`-Wall`、`-Werror`）：-定义字节序为小端（`ANI_LITTLE_BYTE_ENDIAN`）。-定义比特序为小端（`ANI_LITTLE_BIT_ENDIAN`）。-定义主机为小端（`DOT11F_LITTLE_ENDIAN_HOST`）。-定义编译器类型为GCC（`ANI_COMPILER_TYPE_GCC`）。-定义操作系统类型为Android，版本6（`ANI_OS_TYPE_ANDROID=6`）。-启用PTT套接字服务（`PTT_SOCK_SVC_ENABLE`）。-启用所有警告（`-Wall`）。-将所有警告视为错误（`-Werror`）。-定义Linux平台宏（`-D__linux__`）。---```makefileKBUILD_CPPFLAGS+=$(CDEFINES)```-将`CDEFINES`中定义的选项追加到`KBUILD_CPPFLAGS`，这是内核构建系统使用的变量，用于C预处理器标志。---```makefileifneq($(wildcard$(CAMERA_ROOT)/config/camera.conf),)include$(CAMERA_ROOT)/config/camera.confLINUX_INC+=-include$(CAMERA_ROOT)/config/camera.hendif```-检查`camera.conf`文件是否存在（使用`wildcard`函数）。-如果存在，则包含该配置文件（`include`指令）。-同时，将`camera.h`头文件作为强制包含（`-include`）添加到`LINUX_INC`中。---```makefileccflags-y+=$(LINUX_INC)```-将`LINUX_INC`中的头文件路径追加到`ccflags-y`变量。`ccflags-y`是内核构建系统中用于向所有模块传递编译标志的变量（如`-I`路径）。---```makefileifeq($(callcc-option-yn,-Wmaybe-uninitialized),y)EXTRA_CFLAGS+=-Wmaybe-uninitializedendif```-使用`cc-option-yn`函数检查编译器是否支持`-Wmaybe-uninitialized`选项（用于警告可能未初始化的变量）。-如果支持（返回`y`），则将`-Wmaybe-uninitialized`添加到`EXTRA_CFLAGS`。---```makefileifeq($(callcc-option-yn,-Wheader-guard),y)EXTRA_CFLAGS+=-Wheader-guardendif```-同样，检查编译器是否支持`-Wheader-guard`（用于检查头文件保护宏）。-如果支持，则添加到`EXTRA_CFLAGS`。---```makefileobj-m+=regulator/obj-m+=lens/obj-m+=flashlight/v4l2/obj-m+=thermal/```-将多个子目录添加到`obj-m`变量中，表示这些目录下的代码将被编译为可加载内核模块（.ko文件）。每个子目录下应该有自己的Kbuild/Makefile来定义具体的模块。---###文件2:Makefile```makefile#SPDX-License-Identifier:GPL-2.0-only#Copyright(C)2018-2022Oplus.Allrightsreserved.```-注释：声明许可证（GPL-2.0-only）和版权信息。---```makefileifneq($(wildcard$(KERNEL_SRC)/android/abi_gki_aarch64.stg),)BOOT_MIXED_BUILD=trueendif```-检查内核源码目录下是否存在文件`android/abi_gki_aarch64.stg`（该文件可能与GKI（GenericKernelImage）相关）。-如果存在，则设置变量`BOOT_MIXED_BUILD=true`（可能表示启用混合构建模式）。---```makefileKBUILD_OPTIONS+=DFT_ROOT=$(KERNEL_SRC)/$(M)```-向`KBUILD_OPTIONS`变量追加一个选项：`DFT_ROOT=$(KERNEL_SRC)/$(M)`。这可能是设置一个自定义的根路径（`DFT_ROOT`）为内核源码路径下的当前模块路径（`M`是当前Makefile所在的目录）。---```makefileKBUILD_OPTIONS+=MODNAME?=dft_dlkm```-向`KBUILD_OPTIONS`追加`MODNAME?=dft_dlkm`。`MODNAME`用于指定模块名称，这里默认设置为`dft_dlkm`（如果未定义则使用此值）。---```makefileifneq($(wildcard$(KERNEL_SRC)/$(DEVICE_MODULES_REL_DIR)/Makefile.include),)include$(KERNEL_SRC)/$(DEVICE_MODULES_REL_DIR)/Makefile.includeendif```-检查设备模块的相对路径下是否存在`Makefile.include`文件。-如果存在，则包含该文件（可能包含设备特定的构建规则或变量）。---```makefileall:EXTRA_SYMBOLS+=$(extra_symbols)```-扩展`all`目标的依赖：在构建`all`时，将变量`extra_symbols`的值追加到`EXTRA_SYMBOLS`变量中。`EXTRA_SYMBOLS`用于指定模块依赖的外部符号表文件（用于解决模块间的符号依赖）。---```makefileall:$(MAKE)-C$(KERNEL_SRC)M=$(M)modules$(KBUILD_OPTIONS)KBUILD_EXTRA_SYMBOLS="$(EXTRA_SYMBOLS)"```-`all`目标的命令：调用内核构建系统来编译模块。-`-C$(KERNEL_SRC)`：切换到内核源码目录。-`M=$(M)`：告诉内核构建系统，模块的源码位于当前目录（`M`是调用make时传递的变量，通常是当前路径）。-`modules`：指定目标为编译模块。-`$(KBUILD_OPTIONS)`：传递额外的构建选项。-`KBUILD_EXTRA_SYMBOLS="$(EXTRA_SYMBOLS)"`：传递额外的符号表文件路径（用于模块符号解析）。---```makefilemodules_install:$(MAKE)INSTALL_MOD_STRIP=1-C$(KERNEL_SRC)M=$(M)modules_install```-`modules_install`目标：安装编译好的模块。-`INSTALL_MOD_STRIP=1`：在安装时剥离调试符号（减小模块大小）。-`modules_install`：安装模块到系统默认模块目录（通常是`/lib/modules/$(KERNELRELEASE)/`）。---```makefile%:$(MAKE)-C$(KERNEL_SRC)M=$(M)$@$(KBUILD_OPTIONS)```-通配符目标（`%`）：匹配任何未明确指定的目标，然后将该目标传递给内核构建系统。例如，执行`makeclean`会匹配到此规则并执行`clean`目标。---```makefileclean:rm-f*.o*.ko*.mod.c*.mod.o*~.*.cmdModule.symversrm-rf.tmp_versions```-`clean`目标：删除当前目录下编译生成的文件和临时目录。-删除所有目标文件（`.o`）、内核模块（`.ko`）、中间文件（`.mod.c`,`.mod.o`）、备份文件（`*~`）、命令文件（`.*.cmd`）和符号文件（`Module.symvers`）。-删除临时目录`.tmp_versions`（用于存储模块版本信息）。---###总结-**Kbuild文件**：主要用于配置模块的编译环境（头文件路径、宏定义等），并指定要编译的子目录。-**Makefile**：定义如何调用内核构建系统来编译、安装和清理模块。它利用内核的构建规则（`kbuild`）来简化模块的构建过程。这两个文件共同工作，确保模块能够正确地与内核一起编译，并处理了设备特定的配置和符号依赖。---§§相关问题§§:1.内核模块构建中`obj-m`和`obj-y`的区别是什么？2.在Kbuild系统中，`ccflags-y`和`EXTRA_CFLAGS`有何不同？3.如何在内核模块中处理多个源文件生成一个模块？4.内核模块安装时`INSTALL_MOD_STRIP=1`的作用是什么？</think>### 逐行解析 Kbuild 文件 ```makefile TOP := $(srctree)/.. ``` - 定义 `TOP` 变量为内核源码树 (`srctree`) 的上一级目录 - `srctree` 是内核构建系统定义的变量，指向内核源码根目录 ```makefile CAMERA_ROOT=$(TOP)/vendor/oplus/kernel/camera ``` - 设置摄像头相关代码的根路径 ```makefile ifeq ($(DEVICE_MODULES_PATH),) DEVICE_MODULES_PATH = $(srctree) else LINUXINCLUDE := $(DEVCIE_MODULES_INCLUDE) $(LINUXINCLUDE) endif ``` - 检查 `DEVICE_MODULES_PATH` 是否已定义 - 如果未定义，将其设置为内核源码根目录 - 如果已定义，将设备模块包含路径添加到 `LINUXINCLUDE` (注意：`DEVCIE` 疑似拼写错误) ```makefile LINUX_INC += -Iinclude/linux \ -Iinclude/linux/drm \ -Iinclude/linux/gunyah \ -Iinclude/linux/gunyah \ # 重复项，可能是冗余 -Iinclude ``` - 添加内核头文件包含路径到 `LINUX_INC` 变量 - `-I` 标志指定编译器搜索头文件的路径 ```makefile CDEFINES += -DANI_LITTLE_BYTE_ENDIAN \ -DANI_LITTLE_BIT_ENDIAN \ -DDOT11F_LITTLE_ENDIAN_HOST \ -DANI_COMPILER_TYPE_GCC \ -DANI_OS_TYPE_ANDROID=6 \ -DPTT_SOCK_SVC_ENABLE \ -Wall \ -Werror \ -D__linux__ ``` - 添加预处理器宏定义和编译选项： - 字节序定义 (小端) - 编译器类型 (GCC) - 操作系统类型 (Android 6) - 启用特定功能 - 警告选项 (`-Wall` 显示所有警告，`-Werror` 将警告视为错误) - 平台宏定义 (`__linux__`) ```makefile KBUILD_CPPFLAGS += $(CDEFINES) ``` - 将自定义宏定义添加到内核构建系统的 C 预处理器标志 ```makefile ifneq ($(wildcard $(CAMERA_ROOT)/config/camera.conf),) include $(CAMERA_ROOT)/config/camera.conf LINUX_INC += -include $(CAMERA_ROOT)/config/camera.h endif ``` - 检查摄像头配置文件是否存在 - 如果存在则包含该配置文件 - 强制包含摄像头头文件 (`-include`) ```makefile ccflags-y += $(LINUX_INC) ``` - 将头文件包含路径添加到模块编译标志 - `ccflags-y` 是内核构建系统中用于模块编译的标志 ```makefile ifeq ($(call cc-option-yn, -Wmaybe-uninitialized),y) EXTRA_CFLAGS += -Wmaybe-uninitialized endif ``` - 检查编译器是否支持 `-Wmaybe-uninitialized` 选项 - 如果支持则添加该警告标志 ```makefile ifeq ($(call cc-option-yn, -Wheader-guard),y) EXTRA_CFLAGS += -Wheader-guard endif ``` - 检查编译器是否支持 `-Wheader-guard` 选项 - 如果支持则添加该头文件保护检查标志 ```makefile obj-m += regulator/ obj-m += lens/ obj-m += flashlight/v4l2/ obj-m += thermal/ ``` - 声明要构建的内核模块目录 - `obj-m` 告诉构建系统这些目录包含要编译为可加载模块的代码 --- ### 逐行解析 Makefile ```makefile # SPDX-License-Identifier: GPL-2.0-only # Copyright (C) 2018-2022 Oplus. All rights reserved. ``` - 许可证声明 (GPL-2.0-only) - 版权信息 ```makefile ifneq ($(wildcard $(KERNEL_SRC)/android/abi_gki_aarch64.stg),) BOOT_MIXED_BUILD=true endif ``` - 检查是否存在 Android GKI (Generic Kernel Image) 相关文件 - 如果存在则设置混合构建标志 ```makefile KBUILD_OPTIONS+= DFT_ROOT=$(KERNEL_SRC)/$(M) ``` - 添加构建选项，定义模块根目录路径 - `DFT_ROOT` 可能是项目特定的变量名 ```makefile KBUILD_OPTIONS += MODNAME?=dft_dlkm ``` - 设置默认模块名称 (dft_dlkm) - `?=` 表示仅在未定义时赋值 ```makefile ifneq ($(wildcard $(KERNEL_SRC)/$(DEVICE_MODULES_REL_DIR)/Makefile.include),) include $(KERNEL_SRC)/$(DEVICE_MODULES_REL_DIR)/Makefile.include endif ``` - 检查设备特定的 Makefile 是否存在 - 如果存在则包含它 ```makefile all: EXTRA_SYMBOLS += $(extra_symbols) ``` - 扩展 `all` 目标，添加额外的符号表文件 - 用于解决模块间的符号依赖 ```makefile all: $(MAKE) -C $(KERNEL_SRC) M=$(M) modules $(KBUILD_OPTIONS) KBUILD_EXTRA_SYMBOLS="$(EXTRA_SYMBOLS)" ``` - 主要构建目标： - `-C $(KERNEL_SRC)` 切换到内核源码目录 - `M=$(M)` 指定外部模块路径 - `modules` 构建目标 - 传递自定义选项和额外符号表 ```makefile modules_install: $(MAKE) INSTALL_MOD_STRIP=1 -C $(KERNEL_SRC) M=$(M) modules_install ``` - 模块安装目标： - `INSTALL_MOD_STRIP=1` 去除调试信息以减小模块大小 - 安装到标准模块目录 ```makefile %: $(MAKE) -C $(KERNEL_SRC) M=$(M) $@ $(KBUILD_OPTIONS) ``` - 通配符目标：将任何未定义的目标传递给内核构建系统 - 例如 `make clean` 会调用内核的 clean 目标 ```makefile clean: rm -f *.o *.ko *.mod.c *.mod.o *~ .*.cmd Module.symvers rm -rf .tmp_versions ``` - 自定义清理目标： - 删除所有编译生成的文件 - 删除临时目录 - 比内核默认清理更彻底 ### 关键机制总结 1. **分层构建**： - 顶层 Makefile 调用内核构建系统 - Kbuild 文件配置模块级编译选项 - 子目录包含各自的构建定义 2. **自定义处理**： - 设备特定配置 (`DEVICE_MODULES_PATH`) - 摄像头特殊处理 (`CAMERA_ROOT`) - 编译器能力检测 (`cc-option-yn`) 3. **符号处理**： - `KBUILD_EXTRA_SYMBOLS` 解决模块间依赖 - `Module.symvers` 文件记录模块符号 4. **Android 集成**： - GKI 检测 (`abi_gki_aarch64.stg`) - Android 特定宏定义 (`ANI_OS_TYPE_ANDROID=6`) 5. **优化选项**： - 安装时去除调试信息 (`INSTALL_MOD_STRIP=1`) - 严格编译检查 (`-Werror -Wall`) ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值