source insight

背景 Read the fucking source code! --By 鲁迅 A picture is worth a thousand words. --By 高尔基 说明： Kernel版本：4.14 ARM64处理器，Contex-A53，双核 使用工具：Source Insight 3.5， Visio 1. 概述 本文将分析 Buddy System 。 Buddy System 伙伴系统，是通过将物理内存划分为页面来进行管理的系统，支持连续的物理页面分配和释放。此外，使用与碎片相关的算法来确保最大的连续页面。 先通过一个例子大体介绍一下原理吧： 空闲的物理页框按大小分组成 0~MAX_ORDER 个链表，每个链表存放页框的大小为2的n次幂，其中n在 0 ~ MAX_ORDER-1 中取值。 假设请求分配 2^8 = 256 个页框块： 检查 n = 8 的链表，检查是否有空闲块，找到了则直接返回； 没有找到满足需求的，则查找 n = 9 的链表，找到 512大小 空闲块，拆分成两个 256大小 块，将其中一个 256大小 块返回，另一个 256大小 块添加到 n = 8 的链表中； 在 n = 9 的链表中没有找到合适的块，则查找 n = 10 的链表，找到1024大小空闲块，将其拆分成 512 + 256 + 256 大小的块，返回需要获取的 256大小 的块

【原创】Linux中断子系统（二）-通用框架处理 背景 Read the fucking source code! --By 鲁迅 A picture is worth a thousand words. --By 高尔基 说明： Kernel版本：4.14 ARM64处理器，Contex-A53，双核 使用工具：Source Insight 3.5， Visio 概述 【原创】Linux中断子系统（一）-中断控制器及驱动分析讲到了底层硬件GIC驱动，以及Arch-Specific的中断代码，本文将研究下通用的中断处理的过程，属于硬件无关层。当然，我还是建议你看一下上篇文章。 这篇文章会解答两个问题： 用户是怎么使用中断的（中断注册）？ 外设触发中断信号时，最终是怎么调用到中断handler的（中断处理）？ 数据结构分析 先来看一下总的数据结构，核心是围绕着struct irq_desc来展开： Linux内核的中断处理，围绕着中断描述符结构struct irq_desc展开，内核提供了两种中断描述符组织形式： 打开CONFIG_SPARSE_IRQ宏（中断编号不连续），中断描述符以radix-tree来组织，用户在初始化时进行动态分配，然后再插入radix-tree中； 关闭CONFIG_SPARSE_IRQ宏（中断编号连续），中断描述符以数组的形式组织，并且已经分配好；

背景 Read the fucking source code! --By 鲁迅 A picture is worth a thousand words. --By 高尔基 说明： Kernel版本：4.14 ARM64处理器，Contex-A53，双核 使用工具：Source Insight 3.5， Visio 1. 概述 【原创】Linux中断子系统（一）-中断控制器及驱动分析 讲到了底层硬件GIC驱动，以及Arch-Specific的中断代码，本文将研究下通用的中断处理的过程，属于硬件无关层。当然，我还是建议你看一下上篇文章。 这篇文章会解答两个问题： 用户是怎么使用中断的（ 中断注册 ）？ 外设触发中断信号时，最终是怎么调用到中断handler的（ 中断处理 ）？ 2. 数据结构分析 先来看一下总的数据结构，核心是围绕着 struct irq_desc 来展开： Linux内核的中断处理，围绕着中断描述符结构 struct irq_desc 展开，内核提供了两种中断描述符组织形式： 打开 CONFIG_SPARSE_IRQ 宏（中断编号不连续），中断描述符以 radix-tree 来组织，用户在初始化时进行动态分配，然后再插入 radix-tree 中； 关闭 CONFIG_SPARSE_IRQ 宏（中断编号连续），中断描述符以数组的形式组织，并且已经分配好；

Source Insight 4.0 统一字体大小 新版4.0的Source Insight做了很大的改变，安装之后，各种类型的标识符字体大小不一，看着很难受。 网上搜了一圈居然没有找到设置统一字体大小的教程，看来一代神器SI越来越少人用了。。。 闲话少说，Source Insight 4.0 设置统一的字体大小的教程如下： View -> Mono Font View source insight 4.0 默认字体修改 以前在3.5版本的Alt+T不好使了，换成Alt+Y，弹出Files type options，在里面修改即可。 ———————————————— 版权声明：本文为CSDN博主「wowocpp」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/wowocpp/article/details/87274027 来源： oschina 链接： https://my.oschina.net/u/4347428/blog/4277926

背景 Read the fucking source code! --By 鲁迅 A picture is worth a thousand words. --By 高尔基 说明： Kernel版本：4.14 ARM64处理器，Contex-A53，双核 使用工具：Source Insight 3.5， Visio 1. 概述 从这篇文章开始，来聊一聊中断子系统。 中断是处理器用于异步处理外围设备请求的一种机制，可以说中断处理是操作系统管理外围设备的基石，此外系统调度、核间交互等都离不开中断，它的重要性不言而喻。 来一张概要的分层图： 硬件层：最下层为硬件连接层，对应的是具体的外设与SoC的物理连接，中断信号是从外设到中断控制器，由中断控制器统一管理，再路由到处理器上； 硬件相关层：这个层包括两部分代码，一部分是架构相关的，比如ARM64处理器处理中断相关，另一部分是中断控制器的驱动代码； 通用层：这部分也可以认为是框架层，是硬件无关层，这部分代码在所有硬件平台上是通用的； 用户层：这部分也就是中断的使用者了，主要是各类设备驱动，通过中断相关接口来进行申请和注册，最终在外设触发中断时，进行相应的回调处理； 中断子系统系列文章，会包括硬件相关、中断框架层、上半部与下半部、Softirq、Workqueue等机制的介绍，本文会先介绍硬件相关的原理及驱动，前戏结束，直奔主题。 2.

背景 Read the fucking source code! --By 鲁迅 A picture is worth a thousand words. --By 高尔基 说明： Kernel版本：4.14 ARM64处理器，Contex-A53，双核 使用工具：Source Insight 3.5， Visio 1. 概述 上篇文章分析到 malloc/mmap 函数中，内核实现只是在进程的地址空间建立好了 vma 区域，并没有实际的虚拟地址到物理地址的映射操作。这部分就是在 Page Fault 异常错误处理中实现的。 Linux内核中的 Page Fault 异常处理很复杂，涉及的细节也很多， malloc/mmap 的物理内存映射只是它的一个子集功能，下图大概涵盖了出现 Page Fault 的情况： 下边就开始来啃啃硬骨头吧。 2. Arm64处理 Page Fault 的异常处理，依赖于体系结构，因此有必要来介绍一下 Arm64 的处理。 代码主要参考： arch/arm64/kernel/entry.S 。 Arm64在取指令或者访问数据时，需要把虚拟地址转换成物理地址，这个过程需要进行几种检查，在不满足的情况下都能造成异常： 地址的合法性，比如以39有效位地址为例，内核地址的高25位为全1，用户进程地址的高25位为全0； 地址的权限检查

2019.11.09 SourceInsight貌似只能识别ANSI编码格式的文件，即英文是ASCII码，中文是GBK码。而我们一般从服务器下载下来的源码通常是Unicode码（一般UTF-8），如此，若直接用SourceInsight工具打开源码文件，则源码中的中文注释会显示为乱码。 解决办法1：把需要的文件先用Notpad++工具打开，在工具栏“编码”>“转为ANSI编码”，然后保存得到的文件，用SourceInsight工具打开中文显示即正常了。 解决办法2：把所有文件批量修改编码格式，参考文章： 怎样批量修改文件的编码格式 链接：https://jingyan.baidu.com/article/e8cdb32b47a1ea37042bad11.html 解决办法3：修改sourceinsight的默认编码格式为ANSI编码格式，参考文章： sourceinsight如何设置默认编码格式？ 链接：https://jingyan.baidu.com/article/6525d4b1977ab3ac7d2e94ec.html　　 简介：sourceinsight是程序猿看代码的神器，尤其底层程序猿用来配合linux进行交叉编译开发，追踪代码极为方便，但我们如何来设置sourceinsight的默认编码格式呢？ 方法/步骤 选项：options-->preferences ---

我们有个方法，是判断系统的账号有没有登录。 public static boolean isAccountLogin(Context context) { String df = "com.z**; AccountManager accountManager = AccountManager.get(context); try { Account[] accounts = accountManager.getAccountsByType(df); if (accounts != null && accounts.length > 0) { Account account = accounts[0]; SDKLogUtils.d("PackageUtils", account.toString()); if (account != null) { return true; } } else { SDKLogUtils.d("PackageUtils", "com.ztemt account is null"); } } catch (Exception var5) { var5.printStackTrace(); } return false; } 这个在8.0以前的手机，完全没问题。但是8.0就有问题。而且改一下target 版本到8.0才有问题。 赶紧查一下。果然8.0变更了。

背景 Read the fucking source code! --By 鲁迅 A picture is worth a thousand words. --By 高尔基 说明： Kernel版本：4.14 ARM64处理器，Contex-A53，双核 使用工具：Source Insight 3.5， Visio 1. 概述 Mutex 互斥锁是Linux内核中用于互斥操作的一种同步原语； 互斥锁是一种休眠锁，锁争用时可能存在进程的睡眠与唤醒，context的切换带来的代价较高，适用于加锁时间较长的场景； 互斥锁每次只允许一个进程进入临界区，有点类似于二值信号量； 互斥锁在锁争用时，在锁被持有时，选择自选等待，而不立即进行休眠，可以极大的提高性能，这种机制（ optimistic spinning ）也应用到了读写信号量上； 互斥锁的缺点是互斥锁对象的结构较大，会占用更多的CPU缓存和内存空间； 与信号量相比，互斥锁的性能与扩展性都更好，因此，在内核中总是会优先考虑互斥锁； 互斥锁按为了提高性能，提供了三条路径处理：快速路径，中速路径，慢速路径； 前戏都已经讲完了，来看看实际的实现过程吧。 2. optimistic spinning 2.1 MCS锁 上文中提到过 Mutex 在实现过程中，采用了 optimistic spinning 自旋等待机制，这个机制的核心就是基于

背景 Read the fucking source code! --By 鲁迅 A picture is worth a thousand words. --By 高尔基 说明： Kernel版本：4.14 ARM64处理器，Contex-A53，双核 使用工具：Source Insight 3.5， Visio 1. 介绍 在 （四）Linux内存模型之Sparse Memory Model 中，我们分析了 bootmem_init 函数的上半部分，这次让我们来到下半部分吧，下半部分主要是围绕 zone_sizes_init 函数展开。 前景回顾： bootmem_init() 函数代码如下： void __init bootmem_init(void) { unsigned long min, max; min = PFN_UP(memblock_start_of_DRAM()); max = PFN_DOWN(memblock_end_of_DRAM()); early_memtest(min << PAGE_SHIFT, max << PAGE_SHIFT); max_pfn = max_low_pfn = max; arm64_numa_init(); /* * Sparsemem tries to allocate bootmem in memory_present(