Linux之系统调用
Linux之系统调用1、背景在应用开发中，我们经常会去操作IO设备，文件，网络，内存等，基本上都是通过高级语音(C/C++,JAVA等)提供的一些标准库或API去操作，那这些是怎么和操作系统联系在一起的呢？答案就是今天的主角–系统调用。
这里我们只讨论：
硬件： Arm64
系统： Linux系统 (Kernel-5.15-rc1)
高级语言： C （glibc-2.34）
模式： 64位 （即未定义CONFIG_COMPAT）
2、什么是系统调用Linux系统分为内核态和用户态，两者是相互隔离的。为了防止各种应用程序可能对系统资源的破坏，用户态的应用程序是没有权限直接去访问系统资源的，当需要访问时，就需要通过系统调用。
系统调用是内核提供给用户态应用程序的一系列统一接口，标准库或API在系统调用的基础上做了进一步抽象和封装。用户态的应用程序可以直接进行系统调用，也可以通过标准库或API来调用
一个系统调用有很多个步骤，其中一个很重要的就是用户态和内核态相互切换，包括CPU模式的切换， 内核栈、用户栈的保护与处理等
大致的流程为：
------------------------- ...
博客主题切换
博客主题切换今天把博客主题从Matery切换为了Butterfly
主要因为：
Butterfly相对更轻量
Butterfly相对更灵活
Hexo博客主题历史Next -> Matery -> Butterfly
lscpu命令详解
lscpu命令详解背景
Kernel源码： v5.15-rc1 (linux-stable)
测试Kernel: v5.4.18 (kylin)
测试系统： KylinOS V10 SP1
注： 分析只针对arm64平台, 以飞腾平台为例
简介**lscpu**： 主要是用来显示CPU结构相关信息对应的help信息：
用法：
lscpu [选项]
显示 CPU 架构信息。
选项：
-a, --all 同时打印在线和离线 CPU (-e 选项默认值)
-b, --online 只打印在线 CPU (-p 选项默认值)
-B, --bytes print sizes in bytes rather than in human readable format
-C, --caches[=<list>] info about caches in extended readable format
-c, --offline 只打印离线 CPU
-J, -- ...
Debian系软件包降级
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
蓝牙之SSP过程分析
[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之蓝牙相关代码浅析
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之中断处理底半部机制
Kernel之中断处理底半部机制[TOC]
主要记录一些整体的概念、框架和简单介绍，不涉及具体的原理和实现细节
背景查看系统相关中断：
cat /proc/interrupts
中断服务程序要求尽量短小精悍，耗时短。但现实情况是中断到来时，需要完成的工作会比较多，需要进行较大量的耗时处理。于是Linux将中断处理程序分成了2部分：顶半部(Top Half)和底半部(Bottom Half)。但并不一定要分成2个部分， 本来中断要处理的工作比较少，则完全没必要底半部，只需要顶半部就足够了。
顶半部主要用于处理一些尽量少的比较紧急的东西，比如紧急的硬件操作，清除中断标志，记录相应中断信息供底半部使用。底半部主要处理中断需要处理的绝大部分工作（比较耗时）。可以被新的中断打断，通常顶半部是不可被中断的。
所以这里主要介绍下底半部相关的一些机制：Linux实现中断底半部的机制主要有tasklet、工作队列(work queue)、软中断(softirq)、中断线程化(threaded_irq)
tasklet:执行上下文为软中断，执行时机通常是中断顶半部返回时。不允许睡眠。执行快, 短时期, ...
Kernel之init相关
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之最简单字符设备驱动模板
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 ...
kernel之工作队列workqueue
背景之前在触摸驱动（比如汇顶等）的代码里，会看到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
背景我们常用cmdline去控制某些功能的开启或关闭，或是传递一些参数。在系统下，我们可以使用cat /proc/cmdline来查看启动参数，那uboot或是grub的启动参数cmdline是怎么传递解析的呢？
传递与解析以arm64为例，流程图：
early_param --> obs_kernel_param(.init.setup段) ----
|
---> do_early_param (匹配，处理，执行`early_param`中的处理函数)
|
(uefi) -------> fdt ------> boot_command_line ----
early_param以常用的loglevel参数为例，
static int ...