蜗窝科技

Linux时间子系统之（二）：软件架构

作者：linuxer 发布于：2015-3-7 18:37 分类：时间子系统

本文的主要内容是描述内核时间子系统的软件框架。首先介绍了从旧的时间子系统迁移到新的时间子系统的源由，介绍新的时间子系统的优势。第三章汇整了时间子系统的相关文件以及内核配置。最后描述各种内核配置下的时间子系统的数据流和控制流。

阅读全文>>

标签: 软件框架 时间子系统

评论(34) 浏览(55804)

计算机科学基础知识（四）: 动态库和位置无关代码

作者：linuxer 发布于：2015-3-6 9:39 分类：基础学科

本文主要描述了动态库以及和动态库有紧密联系的位置无关代码的相关资讯。首先介绍了动态库和位置无关代码的源由，了解这些背景知识有助于理解和学习 动态库。随后，我们通过加-fPIC和不加这个编译选项分别编译出两个relocatable object file，看看编译器是如何生成位置无关代码的。最后，我们自己动手编写一个简单的动态库，并解析了一些symbol Visibility、动态符号表等一些相关基本概念。

本文中的描述是基于ARM MCU，GNU/linux平台而言的，本文是个人对动态库的理解，如果有错误，请及时指出。

阅读全文>>

标签: 动态库 PIC 位置无关代码

评论(4) 浏览(31819)

Linux电源管理(14)_从设备驱动的角度看电源管理

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

相信工作稍微久一点的linux驱动工程师都深有体会：

在旧时光里，实现某一个设备的电源管理功能，是非常简单的一件事情。大多数设备都被抽象为platform设备，driver只需要提供suspend/resume/shutdown等回调函数，并注册到kernel即可。kernel会在系统电源状态切换的过程中，调用driver提供的回调函数，切换设备的电源状态。

但是在新时代中，设备电源管理有关的操作，被统一封装在struct dev_pm_ops结构中了。该结构包含20多个回调函数，再加上复杂的电源管理机制（常规的suspend/resume、runtime PM等等），使设备驱动的电源管理工作不再那么单纯，工程师（如蜗蜗自己）的思路也不再特别清晰。

因此本文希望能以单一设备的电源管理为出发点，结合kernel的电源管理机制，介绍怎样在设备驱动中添加电源管理功能，并分析设备电源状态切换和系统电源状态切换的关系。

另外，我们在电源管理系列文章中，介绍了很多的电源管理机制，如generic PM、wakeup event framework、wakelock、autosleep、runtime PM、PM domain、等等，本文也算是对它们的梳理和总结。

阅读全文>>

标签: Device driver PM

评论(20) 浏览(31488)

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) 浏览(15508)

支持wowo，有这样一块小天地享受技术，感觉棒棒哒！

作者：孤寂的侵凌 发布于：2015-2-25 0:21

希望以后都可以没事来看一看，玩一玩，和wowo以及朋友们讨论一些问题！

评论(6) 浏览(9301)

计算机科学基础知识（三）:静态库和静态链接

作者：linuxer 发布于：2015-2-16 15:15 分类：基础学科

本文是编译、链接和加载系列文章中的第二篇，主要描述静态链接

阅读全文>>

标签: 静态库 静态链接

评论(3) 浏览(20695)

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) 浏览(32376)

计算机科学基础知识（二）:Relocatable Object File

作者：linuxer 发布于：2015-2-9 19:17 分类：基础学科

一个合格的c程序员（也可以叫做软件工程师，这样看起来更高大上，当然，我老婆心情不好的时候总是叫我“死打字的”，基本也能描述这份职业，呵呵） 需要理解编译、链接和加载的过程，而不是仅仅关注c语言的语法和词法。本文主要以此为切入点，描述linux系统下，一个普通的hello world程序的生命历程，并借机灌输一些程序编译时和运行时的基本术语和概念。当然，由于我本人是一个linuxer，因此借用linux来描述这些知 识会方便些，但是对于计算机科学而言，这些东西概念上是类似的，只是实现细节不同而已（windows程序员或者其他程序员可以阅读本文哦）。

本 文也是阅读了Computer System，A programmer’s perspective的第七章的一个读书笔记，方便日后查阅。注：Computer System，A programmer’s perspective绝对是一本值得反复阅读的书籍，强力推荐。

阅读全文>>

标签: Object Relocatable File

评论(11) 浏览(31957)

Linux PM QoS framework(1)_概述和软件架构

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

QOS为Quality Of Service（服务质量）的简称，对PM QoS而言，表示Linux kernel电源管理相关的服务质量。那到底什么是服务质量呢？

我们知道，Linux PM的主要功能，是节省功耗，但同时，会付出一定的性能代价，例如延迟（latency）增加、吞吐量（throughput）下降。可以把PM当作一种服务，把它对性能的影响，类比为服务的质量（QoS）。对性能的影响越大，QoS越低，反之越高。

不过，PM QoS framework的存在，并不是为了定义并测量系统的服务质量（Linux系统对实际的qos没有任何兴趣），而是为了定义一套框架，以满足系统各个实体（如进程、设备驱动等等）对QoS的期望为终极目标。根据实际的场景，这些期望可描述为：xxx不大于某个值；xxx不小于某个值；等等。

这个终极目标，是基于这样的事实：机器是极端的实用主义者。最理想的状况，是刚刚满足系统各个实体对QoS的期望，因而可以在满足需求的同时，最大化的省电。粗俗一点，就是“我能考60分，为什么要多花一点力气去考61分？”。这样的思路，值得我们深思。

本文将基于PM QoS framework整体的软件架构，介绍它的功能、应用场景、使用方式等。

阅读全文>>

标签: Linux PM 电源管理 pm_qos qos

评论(5) 浏览(25776)

Linux时间子系统之（六）：POSIX timer

作者：linuxer 发布于：2015-1-22 18:12 分类：时间子系统

在用户空间接口函数文档中， 我们描述了和POSIX timer相关的操作，主要包括创建一个timer、设定timer、获取timer的状态、获取timer overrun的信息、删除timer。本文将沿着这些用户空间的接口定义来看看内核态的实现。虽然POSIX timer可以基于各种不同的clock创建，本文主要描述real time clock相关的timer。

本文第二章描述了POSIX timer的基本原理，第三章描述系统调用的具体实现，第四章主要讲real time clock的timer callback函数的实现，第五章介绍了timer超期后，内核如何处理信号。

阅读全文>>

标签: timer POSIX

评论(15) 浏览(30772)