Android的linux内核解耦

已于 2023-03-17 16:17:59 修改
阅读量3.7k 收藏 32
点赞数 4
分类专栏： 架构 android boot 文章标签： linux 运维 服务器 Powered by 金山文档
于 2023-01-19 22:00:05 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/dongyi1988/article/details/128731557
版权
android 同时被 3 个专栏收录
25 篇文章 11 订阅
订阅专栏
架构
5 篇文章 1 订阅
订阅专栏
boot
1 篇文章 0 订阅
订阅专栏

android设备内核部分，除android定制性修改外还有芯片供应商、ODM/OEM的修改，为了隔离他们的影响，做了内核解耦部分内容。

1、boot内容

查看Boot Image Header，version 2版本包含内容最多，包括了内核、设备树、根目录、recovery设备树，cmdline。boot拆包与内容解析参考1、Android bootimg kernel（boot.img）

2、linux的ramdisk解耦

2.1、ramdisk加载情况

2.1.1、android 13没有recovery分区

vendor_boot的ramdisk，init_boot 的ramdisk，boot镜像的GKI，system的tmpfs共同加载到RAM。根据命令参数选择正常Boot Android还是Boot recovery。

2.1.2、android 13 AB系统有recovery分区情况

Boot Android还是加载vendor_boot的ramdisk，init_boot 的ramdisk，boot镜像的GKI，system的tmpfs；

Boot recovery加载vendor_boot的ramdisk，init_boot 的ramdisk，boot镜像的GKI，system的tmpfs以及recovery ramdisk。

2.1.3、android 13 non-AB系统有recovery情况

Boot Android还是加载vendor_boot的ramdisk，init_boot 的ramdisk，boot镜像的GKI，system的tmpfs；

Boot recovery加载recovery的GKI和ramdisk，boot镜像的GKI与tmpfs；

2.2、ramdisk加载解析

上面三张图来自android开发者社区，显然大家很难看懂，我们抓下面三个关键来看图：

1、init分了两个阶段，每个阶段使用不同的资源文件，Android和recovery模式均是两个阶段。

2、启动必然要kernel，这个kernel在哪个分区？

3、进入recovery的核心二进制文件/system/bin/recovery以及它的资源文件在哪个分区？

相关内容所在分区整理表格如下

android 13

无recovery分区

android13 AB

有recovery分区

android 13 non-AB

有recovery分区

android模式

1nd init

init_boot分区

init_boot

init_boot

1nd resource

vendor_boot&init_boot

init_boot

init_boot

2nd init

system

system

system

2nd resource

system

system

system

kernel

boot kernel

boot kernel

boot kernel

recovery模式

1nd init

init_boot分区

recovery ramdisk

recovery ramdisk

2nd init

init_boot

recovery ramdisk

recovery ramdisk

kernel

boot kernel

boot kernel

recovery kernel

recovery二进制执行文件

vendor_boot

recovery ramdisk

recovery ramdisk

recovery resource

vendor_boot

recovery ramdisk

recovery ramdisk

2.3、ramdisk加载总结

根据上表分析：

1、android模式加载流程基本相同，init第二阶段均需要是用system里面的ramdisk；

2、recovery模式有recovery分区，则1nd init、2nd init、recovery执行文件与资源文件从recovery加载；否则1nd init、2nd init从init_boot加载，recovery执行文件与资源文件从vendor_boot加载；

3、没有recovery分区情况和AB系统情况一直使用同一内核boot GKI，non-AB系统有recovery分区情况在recovery模式下使用recovery的GKI。

3、linux的Kernel解耦

上图就是android的kernel解耦情况。

generic Kernel是Linus Torvalds维护的linux宏内核、GKI Modules是android定制模块，合称GKI；GKI对外接口是KMI；Vendor Modules是动态加载模块，通过KMI与GKI通信。

但是目前动态加载模块加载与执行效率并不理想，andorid还在优化。

这章关键在理解linux的分支管理与动态加载模块，以及KMI接口。内容多引用官网。

3.1 GKI

android底层是linux，这个linux除Linus Torvalds维护的宏内核外还有下面三方的修改:

1、android system针对linux的定制性修改，例如低内存终止守护进程（一个内存管理系统，可更主动地保留内存）、唤醒锁定（一种 PowerManager 系统服务）、Binder IPC 驱动程序、启动验证用的设备映射dm-mapper、OTA升级用的设备映射快照dm-snapshot、文件系统加密用的fscrypt等等；

2、芯片厂商vendor添加的内核方案，包括电源管理/DVFS、系统基础支持、PCIe和USB等高速外围设备等等；

3、ODM/OEM也有自己内核的方案，例如各家的驱动、外设方案。

现在google要脱离芯片厂商与ODM/OEM影响，对linux进行解耦。

3.2 KMI

3.3 GKI Modules与Vendor Modules

其实都是linux动态加载模块（不知道的自己查询），关键点在KMI的规范与稳定。

system的GKI模块，放置到system_dlkm里面，开机挂载分区安装，system_dlkm编译参考https://source.android.google.cn/docs/core/architecture/partitions/gki-partitions

将新功能配置为 GKI 模块

对于新功能，编辑gki_defconfig并将所需内核功能的配置项从n设置为m ( =m )。在arch/arm64/configs/gki_defconfig和arch/x86/configs/gki_defconfig中设置此设置。
将为该功能生成的 KO ( .ko ) 文件添加到common/modules.bzl的COMMON_GKI_MODULES_LIST部分。按排序顺序添加文件。如果您不确定生成的所有文件，构建将失败并列出要添加到列表中的所有必需的 KO 文件。
将步骤 2 中的同一组 KO 文件添加到common/android/gki_protected_modules以将模块指定为受保护的 GKI 模块，在运行时按升序排序以进行二进制搜索。指定为受保护 GKI 模块的模块仍必须经过 Google 批准才能成为官方受保护模块。
将步骤 2 中的同一组 KO 文件添加到common/android/gki_system_dlkm_modules ，以在运行时按升序排序以进行二进制搜索，以确保将文件复制到内核的out/<androidX-YZ>/dist/system_dlkm.img和out/ androidX-YZ /dist/system_dlkm_staging_archive.tar.gz 。 system_dlkm_staging_archive.tar.gz存档中的模块可用作输入以在平台构建中生成system_dlkm.img 。
提交您的更改以供审核。 GKI 模块是 Android 独有的内核功能，因此不需要向上游提交模块转换补丁。但是，您必须遵循其他准则来提交 Android 通用内核 (ACK) 补丁。

vendor添加动态加载模块官网地址

https://source.android.google.cn/docs/core/architecture/partitions/vendor-odm-dlkm-partition

添加vendor动态加载模块规则

https://source.android.google.cn/docs/core/architecture/kernel/vendor-module-guidelines

4、dtb与dtbo

android系统对dtb也有依赖，例如system、vendor等的挂载、验证。之前写过dtb与dtbo，并示范多层设备叠加层。dtb和dtbo使用分区没有固定，可以参考https://source.android.google.cn/docs/core/architecture/dto/implement

https://blog.csdn.net/dongyi1988/article/details/103995862#t1

5、BootConfig

BootConfig这个和cmdline一样，将配置详细信息从aboot传递到 Android 12 的机制。

现在与android相关的启动参数androidboot.*从内核 cmdline 移至 bootconfig 文件。

配置参考https://source.android.google.cn/docs/core/architecture/bootloader/implementing-bootconfig#examples-and-source

注意到

  1. kernel header是V4才能用；

  1. 可在/proc/bootconfig与设备树initramfs 节点查看信息；

  1. 在linux的/proc下有文件，显然有bootconfig内核模块。

5.1、bootconfig内存使用图

5.2、代码解析

bootconfig结构如上图，parameters段有直接编译到vendor_boot镜像的固定段、bootloader启动时的动态附加段

  1. mkbootimg编译，将指定文件属性配置编译成bootconfig的固定段

mkbootimg的--vendor_bootconfig参数指定文件附加vendor_boot变成bootconfig里面的固定段，指定属性文件与编译参考地址http://aospxref.com/android-13.0.0_r3/xref/packages/modules/Virtualization/microdroid/（该目录下bootconfig.前缀文件）

  1. vendor_boot加载后，bootloader识别模式往bootconfig附加参数（动态附加段）

http://aospxref.com/android-13.0.0_r3/xref/bootable/libbootloader/libxbc/libxbc.c?fi=addBootConfigParameters#addBootConfigParameters

函数addBootConfigParameters

  1. 内核proc模块，按结构图中信息从kernel所占内存获取Bootconfig信息，并变成文件节点/proc/bootconfig（所以这里boot需要V4版本header，才能获取到bootconfig偏移）

proc-$(CONFIG_BOOT_CONFIG) += bootconfig.o

https://cs.android.com/android/kernel/superproject/+/common-android-mainline:common/lib/bootconfig.c;l=3?q=boot&sq=&ss=android%2Fkernel%2Fsuperproject:common%2Flib%2F

  1. init解析/proc/bootconfig成android属性

http://aospxref.com/android-13.0.0_r3/xref/system/core/init/util.cpp#249

6、总结

linux解耦已经初具模型，

Ramdisk二段加载，拆分与android系统无关的启动根目录，变成android依赖根文件系统+其它根文件系统（包括linux系统、vendor、ODM等的文件系统）；

KO模块动态加载，将android定制模块从kernel中剥离，变成GKI modules+原生kernel；

dtbo设备树叠加层，开始主要解决设备硬件多样性，当然也可以把android的底层属性与vendor、硬件设备树信息隔开使用。

bootconfig解析为android属性，非andorid属性内容还是用cmdline。

上面提到的ramdisk、KO模块、dtb、BootConfig（cmdline传参方案）等方案，把android系统启动时需要使用的根目录、动态模块、设备树、启动属性等都隔开。

目前还有缺点，动态加载模块性能还不够。后面可能针对这些内容，镜像/分仓上有新改动。

当接近完美时，也许可以换新的闭源系统了。。。

Kael.dong
关注
  • 4
    点赞
  • 踩
  • 32
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 3
    评论
专栏目录
内核编译-Pixel 6设备Android 13系统编译gki内核并整合KernelSU
学习记录
05-30 3793
如果未下载repo的先走这里流程，如果已经下载，忽略。先测试编译完成的内核是否能使用。手机环境Android13，原内核版本5.10.107.看内核日期是8月份。从官方的内核列表中发现8月份废弃，我就尝试找10月份的，下载。vm Ubuntu 22.04 500g-24g内存。为Pixel6编译内核，需要增加一些配置，和集成。点击下载，会显示这样的内容，把这里所有内容复制。就是下载完成了，接下里可以编译了。以下操作前提：具备全球通上网。以下操作前提：具备全球通上网。以下操作前提：具备全球通上网。
android_kernel_xiaomi_sm8350
02-09
如何向Android Common Kernels提交补丁 最好：对上游Linux进行所有更改。 如果合适，请向后移植到稳定版本。 这些补丁将自动合并到相应的通用内核中。 如果该补丁已在上游Linux中，请发布符合以下补丁要求的补丁反向移植。 更少的好处：在树外开发补丁（从上游Linux的角度来看）。 除非这些问题解决了Android特定的错误，否则除非与进行协调，否则很难接受这些。 如果要继续，请发布符合以下补丁要求的补丁。 常见内核补丁要求 所有补丁必须符合Linux内核编码标准，并通过script/checkpatch.pl 补丁不得破坏用于arm，arm64，x86，x86_64体系结构的gki_defconfig或allmodconfig构建（请参阅 ） 如果未从上游分支合并修补程序，则必须使用修补程序的类型对主题进行标记： UPSTREAM: ， BACKPORT: ，
GKI改造原则、机制和方法
热门推荐
内核工匠
01-29 2万+
Google在android11-5.4分支上开始要求所有下游厂商使用Generic Kernel Image（GKI），需要将SoC和device相关的代码从核心内核剥离到可加载模块中...
Linux字符设备驱动(二) - 与设备驱动模型的关系
最新发布
滴水藏海
05-06 752
cdev与设备驱动模型的关系
基于高通SM6225平台GKI 2.0 小结
wn541200的博客
01-18 2542
第一个GKI 2.0的项目已经完结，做一些总结。GKI 1.0 的时候，我们添加的设备驱动还是编译到boot.img中，在做XTS测试时刷google的boot.img.GKI 2.0 在高通平台无论userdebug版本还是user版本boot.img都为google的boot.img，除了google的东西，任何第3方的驱动都以ko的形式存在。
安卓架构-内核
安卓 高通 bsp ，同行欢迎交流
12-20 3774
安卓架构-内核
Android GKI 架构简介
私房菜
08-15 1万+
本文简单介绍下GKI 相关的知识点，方便更快的了解GKI 概念和架构，如果想要了解细节，还是要看官网并结合实际。
基于Android的HarmonyOS架构分析比较.docx
11-20
HarmonyOS，华为公司推出的新型操作系统，与传统的基于Linux内核的Android系统有着显著的区别。Android系统依赖于Linux内核，提供了丰富的驱动支持，但这也使得内核庞大，增加了开发者的硬件适配负担。而HarmonyOS则...
android面试题
09-15
- Android基于Linux内核，但并不完全符合硬实时操作系统的定义，因为它不能保证所有任务都能在严格的时间限制内完成，因此通常归类为软实时操作系统。 5. **短信长度**： - 一条标准的短信，如果是中文，通常为70...
必看Android-520道高薪面试题集.pdf
08-30
- Android系统分为Linux内核层、硬件抽象层、库和运行时环境、应用程序框架以及应用程序五层结构。 13. **Android的四大组件**： - Activity（活动）、Service（服务）、BroadcastReceiver（广播接收者）、...
Android经典面试题大全.pdf
07-13
1. **Linux内核**：提供基础的硬件抽象和驱动管理，包括内存管理、进程和线程机制。 2. **硬件抽象层(HAL)**：这一层提供了与硬件设备交互的接口，使上层软件与硬件设备的物理实现解耦。 3. **库和Android运行时**...
电子电气架构-车载软件的核心：操作系统内核
03-04
2. **宏内核架构**：宏内核是最常见的一种架构，应用于桌面、服务器和移动操作系统，如Windows、Linux、Android等。宏内核将所有服务运行在内核态，直接访问硬件，提供高效的服务间调用。在汽车领域，宏内核能满足硬...
安卓启动与镜像刷机
书山有路勤为径
05-27 3911
在AOSP系统中,/vendor分区用于存放设备厂商提供的二进制文件和资源。根文件系统镜像通常会包含大部分系统所需要的二进制程序和文件,但不一定会包含所有的bin程序。Android Boot Loader,简称ABL,是Android设备的第一阶段引导程序。gcc编译后的程序默认使用ELF格式,所以我们可以说ELF格式是gcc生成程序的常用格式之一。在Android系统中,大多数重要分区都会设置主备分区,用于实现备份与恢复的功能。userdata - 存储用户数据,如应用数据、下载的文件等。
Android 内核概览
maimang1001的专栏
09-22 5449
Android 内核基于上游。在 Google，LTS 内核会与 Android 专用补丁结合，形成所谓的“Android 通用内核 (ACK)”。较新的 ACK（版本 5.4 及更高版本）也称为 GKI 内核，因为它们支持将与硬件无关的通用核心内核代码和与硬件无关的 GKI 模块分离开来。GKI 内核会与包含系统芯片 (SoC) 和板级代码的硬件专用供应商模块进行交互。GKI 内核与供应商模块之间的交互通过内核模块接口 (KMI) 来实现，该接口由标识供应商模块所需的函数和全局数据的符号列表组成。
Rockchip Android13 GKI开发指南
weixin_43245753的博客
03-04 8301
Rockchip Android13 GKI开发指南
Android 与 Linux内核（学习ing）
weixin_43898134的博客
11-08 3105
Android 与 Linux内核 studying
SM4350平台的GKI和QGKI
weixin_40970718的博客
07-02 8566
关于高通GKI和QGKI lahaina-gki_defconfig – Used for compliance purposes only lahaina-qgki_defconfig – user版本 lahaina-qgki-consolidated_defconfig – 稳定性版本 lahaina-qgki-debug_defconfig – debug版本 ​​​​
出厂安卓11的机型之VAB架构的详细分析
oAiYinSiTan12的博客
08-14 2万+
在安卓11上，谷歌又研究出了个新玩法：VAB架构(又称虚拟AB分区)，而出厂安卓11的新机型，几乎都是VAB架构，似乎是谷歌强制要求的。本帖的目的是，分享我所学习、了解、熟悉到的VAB架构，分享给大家，让各位机友在玩机路上尽量少走弯路、少跑没必要的售后一日游。本帖可能需要一定的玩机知识及经验，如果你看不太懂的话，说明你暂时可能还不会遇到这些问题。好了，废话不多说，我们分析VAB架构之前，我们先来了解一下安卓分区架构历年的发展。先看一张图： ......
GKI跟KMI的关系
mc10141222的博客
04-05 3767
同时，GKI内核映像是一个可裁剪的内核映像，设备开发者需要确保他们删除了不需要的内核模块和驱动程序，以最小化内核映像的大小。如果我们选择使用GKI内核，我们可以从Google提供的官方内核源码中，选择一个适合我们设备硬件配置的内核配置，并生成一个定制的内核映像。具体来说，KMI定义了一组标准的接口和规范，允许内核模块向内核添加新的功能或修改内核行为。但是需要注意的是，boot.img文件不仅仅只包含GKI所编译的内核和Ramdisk，还包含一些额外的信息，如Android的启动程序、内核命令行参数等等。
linux内核uart驱动，使用队列解耦原有的功能函数
05-10
Linux内核UART驱动通常使用队列来解耦原有的功能函数，以提高代码的可读性和可维护性。这种方法的基本思想是将不同的功能分割成独立的模块，每个模块都有一个输入队列和一个输出队列。 输入队列用于接收来自UART接口的数据，处理数据并将结果放入输出队列中。输出队列中的数据可以是控制命令、状态信息或者其他需要传递给上层应用程序的数据。这种方法的优点是可以使编写驱动程序更加简单，易于维护和扩展。 以下是一个使用队列解耦原有功能函数的UART驱动程序的示例： ```c #include <linux/module.h> #include <linux/init.h> #include <linux/fs.h> #include <linux/cdev.h> #include <linux/slab.h> #include <linux/uaccess.h> #include <linux/serial_core.h> #define BUFFER_SIZE 1024 struct uart_device { struct cdev cdev; struct uart_port port; struct mutex mutex; struct work_struct work; struct tasklet_struct tasklet; spinlock_t lock; wait_queue_head_t read_queue; wait_queue_head_t write_queue; char *buf; int head; int tail; }; static int uart_driver_open(struct inode *inode, struct file *file) { struct uart_device *dev; dev = container_of(inode->i_cdev, struct uart_device, cdev); file->private_data = dev; return 0; } static int uart_driver_release(struct inode *inode, struct file *file) { return 0; } static ssize_t uart_driver_read(struct file *file, char __user *buf, size_t count, loff_t *offset) { struct uart_device *dev = file->private_data; ssize_t ret; if (count == 0) return 0; if (wait_event_interruptible(dev->read_queue, dev->head != dev->tail)) return -ERESTARTSYS; mutex_lock(&dev->mutex); if (dev->head > dev->tail) { ret = min_t(ssize_t, count, dev->head - dev->tail); if (copy_to_user(buf, dev->buf + dev->tail, ret)) { ret = -EFAULT; goto out; } dev->tail += ret; } else { ret = min_t(ssize_t, count, BUFFER_SIZE - dev->tail); if (copy_to_user(buf, dev->buf + dev->tail, ret)) { ret = -EFAULT; goto out; } dev->tail = (dev->tail + ret) % BUFFER_SIZE; } out: mutex_unlock(&dev->mutex); return ret; } static ssize_t uart_driver_write(struct file *file, const char __user *buf, size_t count, loff_t *offset) { struct uart_device *dev = file->private_data; ssize_t ret; if (count == 0) return 0; if (wait_event_interruptible(dev->write_queue, dev->head != ((dev->tail - 1 + BUFFER_SIZE) % BUFFER_SIZE))) return -ERESTARTSYS; mutex_lock(&dev->mutex); if (dev->tail > dev->head) { ret = min_t(ssize_t, count, BUFFER_SIZE - dev->tail); if (copy_from_user(dev->buf + dev->tail, buf, ret)) { ret = -EFAULT; goto out; } dev->tail += ret; } else { ret = min_t(ssize_t, count, dev->head - dev->tail); if (copy_from_user(dev->buf + dev->tail, buf, ret)) { ret = -EFAULT; goto out; } dev->tail = (dev->tail + ret) % BUFFER_SIZE; } out: mutex_unlock(&dev->mutex); return ret; } static void uart_driver_work(struct work_struct *work) { struct uart_device *dev = container_of(work, struct uart_device, work); struct uart_port *port = &dev->port; unsigned char c; int i; mutex_lock(&dev->mutex); while (uart_chars_avail(port)) { c = uart_get_char(port); if (dev->head == ((dev->tail - 1 + BUFFER_SIZE) % BUFFER_SIZE)) { /* Buffer is full, drop the incoming character */ continue; } dev->buf[dev->head] = c; dev->head = (dev->head + 1) % BUFFER_SIZE; } mutex_unlock(&dev->mutex); wake_up_interruptible(&dev->read_queue); } static void uart_driver_tasklet(unsigned long data) { struct uart_device *dev = (struct uart_device *)data; struct uart_port *port = &dev->port; unsigned char c; int i; spin_lock(&dev->lock); while (uart_chars_avail(port)) { c = uart_get_char(port); if (dev->head == ((dev->tail - 1 + BUFFER_SIZE) % BUFFER_SIZE)) { /* Buffer is full, drop the incoming character */ continue; } dev->buf[dev->head] = c; dev->head = (dev->head + 1) % BUFFER_SIZE; } spin_unlock(&dev->lock); wake_up_interruptible(&dev->read_queue); } static void uart_driver_start(struct uart_port *port) { struct uart_device *dev = container_of(port, struct uart_device, port); INIT_WORK(&dev->work, uart_driver_work); tasklet_init(&dev->tasklet, uart_driver_tasklet, (unsigned long)dev); spin_lock_init(&dev->lock); init_waitqueue_head(&dev->read_queue); init_waitqueue_head(&dev->write_queue); mutex_init(&dev->mutex); dev->buf = kzalloc(BUFFER_SIZE, GFP_KERNEL); dev->head = 0; dev->tail = 0; uart_write_wakeup(port); } static void uart_driver_stop(struct uart_port *port) { struct uart_device *dev = container_of(port, struct uart_device, port); cancel_work_sync(&dev->work); tasklet_kill(&dev->tasklet); spin_lock_irq(&dev->lock); dev->head = dev->tail = 0; spin_unlock_irq(&dev->lock); kfree(dev->buf); } static struct uart_ops uart_driver_ops = { .tx_empty = uart_tx_empty, .set_mctrl = uart_set_mctrl, .get_mctrl = uart_get_mctrl, .stop_tx = uart_stop_tx, .start_tx = uart_start_tx, .send_xchar = uart_send_xchar, .stop_rx = uart_stop_rx, .enable_ms = uart_enable_ms, .break_ctl = uart_break_ctl, .startup = uart_driver_start, .shutdown = uart_driver_stop, }; static struct uart_driver uart_driver = { .owner = THIS_MODULE, .driver_name = "uart_driver", .dev_name = "ttyUART", .major = 0, .minor = 0, .nr = 1, .cons = NULL, .ops = &uart_driver_ops, }; static int __init uart_driver_init(void) { dev_t devno; int ret; ret = alloc_chrdev_region(&devno, 0, 1, "uart_driver"); if (ret < 0) return ret; cdev_init(&uart_driver.cdev, &uart_driver_ops); uart_driver.cdev.owner = THIS_MODULE; ret = cdev_add(&uart_driver.cdev, devno, 1); if (ret < 0) { unregister_chrdev_region(devno, 1); return ret; } uart_register_driver(&uart_driver); return 0; } static void __exit uart_driver_exit(void) { uart_unregister_driver(&uart_driver); cdev_del(&uart_driver.cdev); unregister_chrdev_region(uart_driver.cdev.dev, 1); } module_init(uart_driver_init); module_exit(uart_driver_exit); MODULE_AUTHOR("Your Name"); MODULE_LICENSE("GPL"); ``` 在这个驱动程序中，我们使用了两个输入队列和一个输出队列。`read_queue` 用于接收来自 UART 的数据，`write_queue` 用于接收要发送到 UART 的数据，`buf` 用于存储接收到的数据。 `wait_event_interruptible` 函数用于等待数据到达队列。`mutex_lock` 和 `mutex_unlock` 函数用于保护共享数据结构。`wake_up_interruptible` 函数用于唤醒等待在队列上的进程。 `uart_driver_work` 和 `uart_driver_tasklet` 函数用于从 UART 中接收数据，并将接收到的数据放入输入队列中。 `uart_driver_start` 和 `uart_driver_stop` 函数用于初始化和清除输入队列和输出队列中的数据。`uart_driver_ops` 结构体包含了驱动程序中使用的 UART 操作。`uart_driver` 结构体包含了驱动程序的基本信息。 通过使用队列解耦原有的功能函数，我们可以将驱动程序中的不同部分分割成独立的模块，使得代码更加简洁、易于维护和扩展。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Kael.dong

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值