DD'Notes

Debian系软件包降级背景最近在折腾Kylin的时候， 不知道什么原因导致升级异常，然后系统的设置都没有了~~~手动安装设置软件包报依赖异常，于是就想降级下软件包 降级软件包此方式应该适用于使用apt包管理器的debain系，已在kylin上验证OK #查看可安装的可用版本 apt-cache showpkg xxx #安装指定版本 sudo apt-get install xxx=version 延伸：apt相关常见错误: 报错: apt-add-repository：找不到命令 sudo apt-get install software-properties-common 常用命令: #对指定包的版本hold住，更新的时候就会忽略掉这个包 sudo apt-mark hold xxx #取消对该包版本的锁定 sudo apt-mark unhold xxx #下载deb包 apt download xxx #下载包源码 sudo apt source xxx #查看依赖 apt-cache depends xxx

[TOC] 背景 Kernel: v5.4.18 Bluetooth：v5.2 Bluez: v5.53 相关概念SSP：Secure Simple PairingOOB: Out of Band Host A: 手机Host B: PC 手机主动连接PC（Linux）的蓝牙，配对走的是SSP，IO Capability Exchange为DisplayYesNo，使用的是Numeric Comparison 这里我们不讨论OOB的情况，所谓OOB就是通过其他渠道途径来交换蓝牙相关的信息，比如通过NFC交换蓝牙双方的MAC地址,配对等 SSP过程分析主流程图(MSC)：BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 2, Part F page 732 主要几个步骤：主要列举与HCI相关的步骤 Enable Simple Pairing:在ssp过程开始之前，两方都需要enable ssp: Start Simple Pairing：只与发起方手机(Host A)有关系: IO capabilities：这步会决定下面Authenti ...

蓝牙相关知识[TOC] 背景蓝牙协议：v5.2蓝牙官网：https://www.bluetooth.com/specifications/specs/ 前段时间，v5.3版本已经发布 主要应用领域 数据传输，主要物联网 音频传输，手机、PC; LE audio(5.2新增),解决了左右耳等时同步传输，LC3编解码器 位置服务，LE Beacon，AoA和AoD(5.1新增)等，可精确到亚米级 设备网络，主要是BLE Mesh、IPv6 Over BLE(IPSP) 几个重要版本 v2.0 + EDR Enhanced Data Rate，2 Mb/s and 3 Mb/s modes 3.0 + HS AMP 4.0 BLE 5.0 2 Msym/s PHY for LE 5.2 LE Isochronous Channels 更多具体细节可参见《Bluetooth Core Specification v5.2》的《CORE SPECIFICATION CHANGE HISTORY》章节从蓝牙协议更新来看，BR/EDR 将逐渐退出历史舞台，LE将成为重点 无线特性 2.4 ...

Linux之蓝牙相关代码浅析[TOC] 主要记录一些整体的概念、框架和简单介绍，不涉及具体的原理和实现细节 Linux协议栈Kernel: v5.4.18Bluez官网：http://www.bluez.org/ Linux蓝牙协议栈Bluez分为内核空间和用户空间2个部分。这里我们先只讨论内核部分。 而内核部分也分为2块：HCI驱动 和 协议栈源码：下面就分这两块分别进行分析 内核蓝牙HCI驱动：路径：/drivers/bluetooth固件：/usr/lib/firmware/、/lib/firmware/等 btsdio -- | btxxx(btrtl，vendor..) btusb --(`/drivers/bluetooth/`)--> hci-core(`/net/bluetooth/`) ...

Kernel之中断处理底半部机制[TOC] 主要记录一些整体的概念、框架和简单介绍，不涉及具体的原理和实现细节 背景查看系统相关中断： cat /proc/interrupts 中断服务程序要求尽量短小精悍，耗时短。但现实情况是中断到来时，需要完成的工作会比较多，需要进行较大量的耗时处理。于是Linux将中断处理程序分成了2部分：顶半部(Top Half)和底半部(Bottom Half)。但并不一定要分成2个部分， 本来中断要处理的工作比较少，则完全没必要底半部，只需要顶半部就足够了。 顶半部主要用于处理一些尽量少的比较紧急的东西，比如紧急的硬件操作，清除中断标志，记录相应中断信息供底半部使用。底半部主要处理中断需要处理的绝大部分工作（比较耗时）。可以被新的中断打断，通常顶半部是不可被中断的。 所以这里主要介绍下底半部相关的一些机制：Linux实现中断底半部的机制主要有tasklet、工作队列(work queue)、软中断(softirq)、中断线程化(threaded_irq) tasklet:执行上下文为软中断，执行时机通常是中断顶半部返回时。不允许睡眠。执行快, 短时期, ...

Kernel之init相关[TOC] 主要记录一些整体的概念、框架和简单介绍，不涉及具体的原理和实现细节 背景在看驱动代码的时候经常会看到module_init、subsys_initcall等xxx_init相关的代码，以前只知道是该驱动最开始入口函数的地方，并没有深究到底层去，最近刚好又碰到，就想看看底层是什么样的，于是就有了此文。 xxx_init相关初始化函数这里主要列举了module_init和subsys_initcall相关实现，其他类似 subsys_initcall:#ifndef MODULE /*...*/ /* 不是模块时 */ #define subsys_initcall(fn) __define_initcall(fn, 4) /*...*/ #endif /* 为模块时 */ #define subsys_initcall(fn) module_init(fn) module_init:#ifndef MODULE /*...*/ /* 不是模块时 */ #define module_init(x) __initcall(x); /*...*/ ...

kernel之字符设备驱动模块一个最简单的字符驱动模板： /* 设备结构体 */ struct xxx_dev_t { struct cdev cdev; ... } xxx_dev; /* 读设备 */ static ssize_t xxx_read(struct file *filp, char __user *buf, size_t size, loff_t *ppos) { ... copy_to_user(buf, ..., ...); /* 拷贝数据到用户空间 */ ... } /* 写设备 */ static ssize_t xxx_write(struct file *filp, const char __user *buf, size_t size, loff_t *ppos) { ... copy_from_user(..., buf, ...); /* 从用户空间拷贝数据到内核空间 */ ... } /* 文件操作集 */ static const struct fil ...

背景之前在触摸驱动（比如汇顶等）的代码里，会看到INIT_WORK等相关字眼，只知道是和工作队列相关，没有深入研究学习。最近在看蓝牙HCI相关代码中，又看到了INIT_WORK等，觉得工作队列（workqueue）需要好好看看，并记录下 工作队列通常用于将耗时工作滞后处理，比如中断处理的下半部耗时操作，等， 中断相关的处理机制可见：《Kernel之中断处理底半部机制》。 最新的 workqueue 实现叫做 CMWQ(Concurrency Managed Workqueue)，也就是用更加智能的算法来实现“并行和节省”。 Kernel： v5.4.18 几个概念很容易混淆的几个概念： work ：工作。 workqueue ：工作的集合。workqueue 和 work 是一对多的关系。 worker ：工人。在代码中 worker 对应一个 work_thread() 内核线程。 worker_pool：工人的集合。worker_pool 和 worker 是一对多的关系。 pwq(pool_workqueue)：中间人 / 中介，负责建立起 workqueue 和 worker ...

背景我们常用cmdline去控制某些功能的开启或关闭，或是传递一些参数。在系统下，我们可以使用cat /proc/cmdline来查看启动参数，那uboot或是grub的启动参数cmdline是怎么传递解析的呢？ 传递与解析以ARM64平台，early_param()为例流程图： early_param --> obs_kernel_param(.init.setup段) ---- | ---> do_early_param (匹配，处理，执行`early_param`中的处理函数) | (uefi) -------> fdt ------> boot_command_line ---- early_param以常用的logleve ...

问题及解决最近在升级系统的时候，遇到一个很奇怪的问题，报错如下： 正在设置 network-manager (1.22.10-1xxxx8) ... ln: 无法创建符号链接'/etc/resolv.conf': 不允许的操作 dpkg: 处理软件包 network-manager (--configure)时出错： 已安装 network-manager 软件包 post-installation 脚本 子进程返回错误状态 1 dpkg: 依赖关系问题使得 network-manager-gnome 的配置工作不能继续： network-manager-gnome 依赖于 network-manager (>= 1.8)；然而： 软件包 network-manager 尚未配置。 然后查看了下/etc/resolv.conf文件，是个只读文件；且无法使用chmod更改权限，更没法mv或rm 后面在网上搜到了解决方案，使用 chattr 命令可以解除这个限制，更改文件的相关属性： # 首先查看相关属性，看有没有 i 属性 su ...

likely与unlikely函数if (unlikely(ac.nodemask != nodemask)) { ... } 使用likely ，执行if后面语句的可能性大些，编译器将if{}是的内容编译到前面, 使用unlikely ，执行else后面语句的可能性大些,编译器将else{}里的内容编译到前面。这样有利于cpu预取,提高预取指令的正确率,因而可提高效率总之,likely与unlikely互换或不用都不会影响程序的正确性。但可能会影响程序的效率。支声明对于条件选择语句，gcc内建了一条指令用于优化，在一个条件经常出现，或者该条件很少出现的时候，编译器可以根据这条指令对条件分支选择进行优化。内核把这条指令封装成了宏，比如likely()和unlikely()，这样使用起来比较方便。

背景 kernel： v5.4.18 最近在合一个蓝牙驱动，遇到一个需要注意的小细节，特此记录！驱动打成Y，没问题；打成M，有问题后来定位问题在#ifdef CONFIG_XXX，使用#if IS_ENABLED(CONFIG_XXX)替换解决，为什么呢？ 分析首先要分析config文件(.config)里面的配置CONFIG_XXX是怎么影响内核源码里面的C文件的？执行make menuconfig并保存配置后，会根据config文件(.config)自动生成autoconf.h文件，并自动包含到内核源码中，里面的内容类似如下： #define CONFIG_XXX 1 #define CONFIG_XXX_MODULE 1 配置文件里面的CONFIG_XXX=y会转化生成为#define CONFIG_XXX 1,CONFIG_XXX=m会转化生成为#define CONFIG_XXX_MODULE 1;这个就是问题关键所在！ #ifdef CONFIG_XXX只判断CONFIG_XXX，并没有判断模块形式的CONFIG_XXX_MODULE而IS_ENABLED呢？ 再来看 ...