蜗窝科技

Linux kernel内核配置解析(1)_概述(基于ARM64架构)

作者：wowo 发布于：2016-8-10 23:20 分类：Linux内核分析

对刚接触Linux kernel的同学来说，遇到的第一个问题就是：我该从哪里入手？、

话说Linux kernel的打开方式是多种多样的：从简单的设备驱动入手；从源代码的目录结构入手；从kernel的启动过程入手；从大的功能模块入手；等等。不管怎样，每条都是正途（条条大路通罗马嘛）。

而本文（以及随后的系列文章），将从Linux kernel的配置项入手，从整体上认识Linux kernel。之所以这么做，原因有二：

1）Linux kernel的配置项数目繁多，以至于进行kernel移植的时候，看到menuconfig界面后，会有深深的恐惧感（可参考下面图片1）。

2）配置项的目的，是功能配置和功能开关，从一定程度上可以看出一个软件的功能模块划分。以Linux kernel为例，Kconfig所呈现出来的树状结构，从功能划分的角度看，比source code的目录结构还清晰。

注1：本系列文章使用的Linux kernel版本是“X Project”所用的“Linux 4.6-rc5”，具体可参考“https://github.com/wowotechX/linux.git”。

阅读全文>>

标签: Linux Kernel 内核 配置项 menuconfig

评论(2) 浏览(22249)

总结Linux kernel开发中0的巧妙使用

作者：snail 发布于：2015-7-20 17:53

kernel的源代码中，有很多令人拍案叫好的用法，此文简单总结了一下，我所知道的0的巧妙用法，权当抛砖引玉，希望
能激发起读者相当更多的0的用法。

阅读全文>>

标签: Kernel panic 空指针

评论(6) 浏览(13910)

Linux PM QoS framework(3)_per-device PM QoS

作者：wowo 发布于：2015-2-26 22:44 分类：电源管理子系统

per-device PM QoS是针对指定设备的QoS framework，背后的思考如下：

1）resume_latency

在Runtime PM的框架下，当device的引用计数减为0的时候，RPM会suspend该device。不过，device进入suspend状态以及从suspend状态resume是需要消耗时间的（相关信息保存在pm domain中），而系统其它实体（如用户空间程序）可能对该设备的响应时间有要求，这就是一种形式的QoS request，称作resume_latency。

per-device PM QoS framework会提供相应的接口，收集指定设备的resume_latency request，并提供给Runtime PM，它在suspend设备时，会考虑这种需求，并决定是否suspend设备。

2）latency_tolerance

一些复杂的设备，在运行状态（active）时，为了节省功耗，也有可能自行进入某些省电状态，相应的，设备的响应速度可能降低。如果该设备足够智能，可能会提供一个回调函数（.set_latency_tolerance，位于dev_pm_info结构中），以便设置最大的延迟容忍时间。这称作latency_tolerance。

对per-device PM QoS来说，需要提供一种机制，收集所有的、针对某个设备的latency_tolerance需求，并汇整出可以满足所有需求的latency_tolerance，通过设备的回调函数告知设备。

3）no power off/remote wakeup

在Runtime PM的框架下，设备suspend之后，还可以进一步通过pm domain关闭该设备的供电，以节省功耗。但关闭供电时，除了要考虑对设备resume_latency的需求之外，还要考虑该设备是否允许关闭供电，以及该设备是否需要作为一个唤醒源（remote wakeup）。

这是另一种形式的QoS request，称作per-device PM QoS flag，表示系统其它实体对该设备的一些特定行为的需求。当前的flag有两种：

PM_QOS_FLAG_NO_POWER_OFF，表示不允许设备断电
PM_QOS_FLAG_REMOTE_WAKEUP，表示设备应具备唤醒功能

这两个flag可以通过或操作，同时生效。

因此，per-device PM QoS framework的功能，就是抽象上面两类需求，包括：向requestor提供QoS request的add、update、remove等API，包括内核空间API和用户空间API；汇整、整理这些request；向电源管理有关的service（主要是pm domain framework）提供汇整后的request信息，以便这些service可以做出正确的决定。

下面将会结合source code(位于drivers/base/power/qos.c中），介绍上面的实现逻辑。

阅读全文>>

标签: Linux Kernel pm_qos per-device

评论(9) 浏览(15507)

Linux PM QoS framework(2)_PM QoS class

作者：wowo 发布于：2015-2-10 23:09 分类：电源管理子系统

回顾上一篇文章（Linux PM QoS framework(1)_概述和软件架构），PM QoS framework抽象出4个系统级别的QoS constraint（统称为PM QoS class），分别是cpu&dma latency、network latency、network throughput和memory bandwidth。并提供一系列的接口，动态的搜集、整理系统对这些constraint的需求情况。

阅读全文>>

标签: Linux Kernel pm_qos qos

评论(7) 浏览(32375)

Linux电源管理(13)_Driver的电源管理

作者：Physh 发布于：2014-12-26 18:31 分类：电源管理子系统

首先，回想一下wowo电源管理系列文章中提到的几个PM特性：

A. Wake Count/Wake Source

B. Wake Lock

C. Auto Sleep

D. Runtime Suspend

这篇文章就简单简单整理一下以上特性的在Driver中的使用场景，理解可能有偏差，大家多指教。

阅读全文>>

标签: Kernel driver

评论(32) 浏览(34610)

Linux电源管理(12)_Hibernate功能

作者：Physh 发布于：2014-12-22 11:51 分类：电源管理子系统

本文简要分析了Linux一种Hibernation实现机制——Swap Suspend的是实现方法。本文会尽量从机制出发，不会深入代码分析，如果您感兴趣，可以参照附件给出的流程图，阅读内核代码，相信您也可以找到其中乐趣。

A. Swap Suspend的原因

B. 如何实现STF

C. Swap Suspend的关键

阅读全文>>

标签: Kernel hibernation

评论(23) 浏览(24990)

新技能get: 订阅Linux内核邮件列表

作者：wowo 发布于：2014-11-4 22:37 分类：Linux应用技巧

本文给小伙伴们分享一下怎么订阅Linux内核邮件列表（Linux kernel mailing list，LKML）。

阅读全文>>

标签: Linux Kernel mailing list LKML

评论(25) 浏览(54468)

Linux电源管理(1)_整体架构

作者：wowo 发布于：2014-5-7 19:21 分类：电源管理子系统

在这个世界中，任何系统的运转都需要能量。如树木依靠光能生长，如马儿依靠食物奔跑，如计算机系统依靠电能运行。而能量的获取是有成本的，因此如果能在保证系统运转的基础上，尽量节省对能量的消耗，就会大大提升该系统的生存竞争力。这方面，大自然已经做的很好了，如植物的落叶，如动物的冬眠，等等。而在计算机的世界里（这里以运行Linux OS的嵌入式系统为例），称作电源管理（Power Management）。

通俗的讲，电源管理就是：“想让马儿跑，不想马吃草”。不过，从能量守恒的角度，想让马儿跑多快、跑多久，就一定要让它吃相应数量的草。那么我们就退而求其次：“只在需要马儿跑时，才让它吃草”。这就是电源管理的核心思想。那方法呢？

阅读全文>>

标签: Kernel management PM Power Architecture

评论(48) 浏览(90664)

Linux设备模型(8)_platform设备

作者：wowo 发布于：2014-4-28 10:24 分类：统一设备模型

在Linux设备模型的抽象中，存在着一类称作“Platform Device”的设备，内核是这样描述它们的（Documentation/driver-model/platform.txt）：

Platform devices are devices that typically appear as autonomous entities in the system. This includes legacy port-based devices and host bridges to peripheral buses, and most controllers integrated into system-on-chip platforms.  What they usually have in common is direct addressing from a CPU bus.  Rarely, a platform_device will be connected through a segment of some other kind of bus; but its registers will still be directly addressable.

概括来说，Platform设备包括：基于端口的设备（已不推荐使用，保留下来只为兼容旧设备，legacy）；连接物理总线的桥设备；集成在SOC平台上面的控制器；连接在其它bus上的设备（很少见）。等等。

这些设备有一个基本的特征：可以通过CPU bus直接寻址（例如在嵌入式系统常见的“寄存器”）。因此，由于这个共性，内核在设备模型的基础上（device和device_driver），对这些设备进行了更进一步的封装，抽象出paltform bus、platform device和platform driver，以便驱动开发人员可以方便的开发这类设备的驱动。

可以说，paltform设备对Linux驱动工程师是非常重要的，因为我们编写的大多数设备驱动，都是为了驱动plaftom设备。本文我们就来看看Platform设备在内核中的实现。

阅读全文>>

标签: Linux Kernel 设备模型 platform设备

评论(34) 浏览(79210)

Linux设备模型(7)_Class

作者：wowo 发布于：2014-4-23 15:17 分类：统一设备模型

在设备模型中，Bus、Device、Device driver等等，都比较好理解，因为它们对应了实实在在的东西，所有的逻辑都是围绕着这些实体展开的。而本文所要描述的Class就有些不同了，因为它是虚拟出来的，只是为了抽象设备的共性。

举个例子，一些年龄相仿、需要获取的知识相似的人，聚在一起学习，就构成了一个班级（Class）。这个班级可以有自己的名称（如295），但如果离开构成它的学生（device），它就没有任何存在意义。另外，班级存在的最大意义是什么呢？是由老师讲授的每一个课程！因为老师只需要讲一遍，一个班的学生都可以听到。不然的话（例如每个学生都在家学习），就要为每人请一个老师，讲授一遍。而讲的内容，大多是一样的，这就是极大的浪费。

设备模型中的Class所提供的功能也一样了，例如一些相似的device（学生），需要向用户空间提供相似的接口（课程），如果每个设备的驱动都实现一遍的话，就会导致内核有大量的冗余代码，这就是极大的浪费。所以，Class说了，我帮你们实现吧，你们会用就行了。

这就是设备模型中Class的功能，再结合内核的注释：A class is a higher-level view of a device that abstracts out low-level implementation details(include/linux/device.h line326)，就容易理解了。

阅读全文>>

标签: Linux Kernel 内核 设备模型 class

评论(39) 浏览(46240)