2016年06月_wh8_2011

转载 read()/write()的生命旅程——前言与目录

read()/write()是libc最常用的库函数，那么在application调用了read()/write()之后，发生了哪些事情，数据经过了怎样的流程才从media上读出到用户的buffer里，或是从用户buffer被写到media上的呢？本文将通过以下章节详细阐述整个过程。第一章：文件系统基础整个文件系统Overview从libc到SYSCALLVFS的分发

2016-06-30 08:05:10 868

转载 read()/write()的生命旅程之二——第二章：read()

本章将介绍read()系统调用的过程。回忆一下第一章里讲到的read()系统调用发生后VFS将调用文件实际所在文件系统的file_operations.read()，我们就从这个地方开始。 1. read()：从file operation到page cache这个过程是在file_operation.read()的核心函数：do_generic_file_read()中完

2016-06-30 08:04:36 1001

转载 read()/write()的生命旅程之三——第三章：write()

本章将介绍write()系统调用的过程。和第二章read()一样我们将从file_operations.write()开始。 1. write()：从file operation到page cachefile_operations.write()的核心函数是generic_perform_write()。大部分文件系统的file_operations.write()

2016-06-30 08:03:35 3284 1

转载 read()/write()的生命旅程之五——第五章：从bio到media

第四章中writeback thread已经将要写的page或inode(meta data)变成了bio，bio就是已经对应到了block device的哪一块了。本章我们就要搞清楚最后一步，即bio是怎样写到实际的存储media上的。下面这张图从submit_bio开始，揭示了bio最后被写到media上的过程。从上图可以看到，写到media的过程以submit_bio

2016-06-30 08:02:29 1123

转载 read()/write()的生命旅程之四——第四章：writeback

第三章write()中已经提到要写的page加到了writeback queue后将有writeback thread将其真正写到block device上，而不是每一次写都直接写到media上。如果要绕过writeback机制直接写到media上，在open()的时候指定O_DIRECT即可。Writeback机制的好处总结起来主要是两点：加快write()的响应速度。因为media的读

2016-06-30 08:01:21 2358

转载 H264 视频文件帧格式

rfc3984Standards Track [Page 2] RFC 3984 RTP Payload Format for H.264 Video February 2005 1.按照RFC3984协议实现H264视频流媒体nalu单元包起始 0x 00 00 00 01H．264 NAL格式及分析器http://hi.baidu.com/zsw_davy/b .

2016-06-29 18:46:39 6067

转载 h264 图像、帧、片、NALU

H.264 是一次概念的革新，它打破常规，完全没有 I 帧、P帧、B 帧的概念，也没有 IDR帧的概念。对于 H.264中出现的一些概念从大到小排序依次是：序列、图像、片组、片、NALU、宏块、亚宏块、块、像素。这里有几点值得说明：（1）、在 H.264协议中图像是个集合概念，顶场、底场、帧都可以称为图像（本文图像概念时都是集合概念）。因此我们可以知道，对于H.264 协议来说，我们平常所熟悉

2016-06-29 18:23:36 1483

转载 linux下数据同步、回写机制分析

一、前言在linux2.6.32之前，linux下数据同步是基于pdflush线程机制来实现的，在linux2.6.32以上的版本，内核彻底删掉了pdflush机制，改为了基于per-bdi线程来实现数据同步，与pdflush线程相比，在per-bdi线程机制中，每个后备存储器拥有自己唯一的回写线程，数据同步时需要更少的线程、也不会有多个pdflush对同一个后备存储器进行回写的竞态问题，回写

2016-06-29 09:46:50 1585

转载 h264 流、帧结构

H264元素的分层结构H.264编码器输出的Bit流中，每个Bit都隶属于某个句法元素。句法元素被组织成有层次的结构，分别描述各个层次的信息。在H.264 中，句法元素共被组织成序列、图像、片、宏块、子宏块五个层次。在这样的结构中，每一层的头部和它的数据部分形成管理与被管理的强依赖关系，头部的句法元素是该层数据的核心，而一旦头部丢失，数据部分的信息几

2016-06-28 18:55:42 1288

转载 RTP协议全解（H264码流和PS流）

在前面：RTP的解析，网上找了很多资料，但是都不全，所以我力图整理出一个比较全面的解析，其中借鉴了很多文章，我都列在了文章最后，在此表示感谢。互联网的发展离不开大家的无私奉献，我决定从我做起，希望大家支持。原创不易，转载请附上链接，谢谢http://blog.csdn.net/chen495810242/article/details/39207305 1、RT

2016-06-28 18:21:21 790

转载 pdflush进程详解

以下转自：http://blog.csdn.net/kofshower/article/details/7357968大家知道，在linux操作系统中，写操作是异步的，即写操作返回的时候数据并没有真正写到磁盘上，而是先写到了系统cache里，随后由pdflush内核线程将系统中的脏页写到磁盘上，在下面几种情况下，系统会唤醒pdflush回写脏页：1 、定时方式：

2016-06-28 09:40:22 557

转载 linux驱动程序调试常用方法

驱动程序开发的一个重大难点就是不易调试。本文目的就是介绍驱动开发中常用的几种直接和间接的调试手段，它们是：利用printk查看OOP消息利用strace利用内核内置的hacking选项利用ioctl方法利用/proc 文件系统使用kgdb一、利用printk这是驱动开发中最朴实无华，同时也是最常用和有效的手段。scull驱动的main.c第338行如下，就是使用printk

2016-06-27 08:03:56 3218

转载 linux内核部件分析之——设备驱动模型之class

前面看过了设备驱动模型中的bus、device、driver，这三种都是有迹可循的。其中bus代表实际的总线，device代表实际的设备和接口，而driver则对应存在的驱动。但本节要介绍的class，是设备类，完全是抽象出来的概念，没有对应的实体。所谓设备类，是指提供的用户接口相似的一类设备的集合，常见的设备类的有block、tty、input、usb等等。 class对应的代码

2016-06-20 09:47:25 556

上节我们分析设备驱动模型中的device，主要是drivers/base/core.c，可以说是代码量最大的一个文件。本节要分析的驱动driver，就要相对简单很多。原因也很简单，对于driver，我们能定义的公共部分实在不多，能再sysfs中表达的也很少。本节的分析将围绕drivers/base/driver.c，但头文件仍然是include/linux/device.h和drivers/bas

2016-06-19 10:52:38 752

转载 Linux内核部件分析设备驱动模型之device

linux的设备驱动模型，是建立在sysfs和kobject之上的，由总线、设备、驱动、类所组成的关系结构。从本节开始，我们将对linux这一设备驱动模型进行深入分析。头文件是include/linux/device.h，实现在drivers/base目录中。本节要分析的，是其中的设备，主要在core.c中。struct device { struct de

2016-06-19 10:51:40 2248

转载 Linux内核部件分析设备驱动模型的基石kobject

之前我们分析了引用计数kref，总结了sysfs提供的API，并翻译了介绍kobject原理及用法的文档。应该说准备工作做得足够多，kobject的实现怎么都可以看懂了，甚至只需要总结下API就行了。可我还是决定把kobject的实现代码从头分析一遍。一是因为kobject的代码很重要，会在设备驱动模型代码中无数次被用到，如果不熟悉的话可以说是举步维艰。二是为了熟悉linux的编码风格，为以后分析

2016-06-19 10:50:51 1251

转载 Linux内核部件分析更强的链表klist

前面我们说到过list_head，这是linux中通用的链表形式，双向循环链表，功能强大，实现简单优雅。可如果您认为list_head就是链表的极致，应该在linux链表界一统天下，那可就错了。据我所知，linux内核代码中至少还有两种链表能占有一席之地。一种就是hlist，一种就是本节要介绍的klist。虽然三者不同，但hlist和klist都可以看成是从list_head中发展出来的，用于特殊

2016-06-19 10:49:52 433

转载 Linux内核部件分析记录生命周期的kref

kref是一个引用计数器，它被嵌套进其它的结构中，记录所嵌套结构的引用计数，并在计数清零时调用相应的清理函数。kref的原理和实现都非常简单，但要想用好却不容易，或者说kref被创建就是为了跟踪复杂情况下地结构引用销毁情况。所以这里先介绍kref的实现，再介绍其使用规则。kref的头文件在include/linux/kref.h，实现在lib/kref.c。闲话少说，上代码。s

2016-06-19 10:49:05 472

转载 Linux内核部件分析原子性操作atomic_t

在任何处理器平台下，都会有一些原子性操作，供操作系统使用，我们这里只讲x86下面的。在单处理器情况下，每条指令的执行都是原子性的，但在多处理器情况下，只有那些单独的读操作或写操作才是原子性的。为了弥补这一缺点，x86提供了附加的lock前缀，使带lock前缀的读修改写指令也能原子性执行。带lock前缀的指令在操作时会锁住总线，使自身的执行即使在多处理器间也是原子性执行的。xchg指令不带lock前

2016-06-19 10:48:20 413

转载 Linux内核部件分析连通世界的list

在linux内核中，有一种通用的双向循环链表，构成了各种队列的基础。链表的结构定义和相关函数均在include/linux/list.h中，下面就来全面的介绍这一链表的各种API。struct list_head { struct list_head *next, *prev; }; 这是链表的元素结构。因为是循环链表，表头和表中节点都是这一结构。有prev和

2016-06-19 10:47:25 412

转载 Linux内核部件分析设备驱动模型之device-driver

前面我们分析了device、driver、bus三种类型，主要是三者的注册与注销，在sysfs中的目录与属性文件创建等内容。本节就来详细分析下，在设备注册到总线上时，总线是如何为其寻找对应的驱动的；在驱动注册到总线上时，总线又是如何为其寻找对应的设备的。本节的实现代码集中在drivers/base/bus.c和drivers/base/dd.c中。先来回忆下，在device_reg

2016-06-19 10:46:12 1906

转载 Linux内核部件分析设备驱动模型之bus

前面我们分析了设备驱动模型中的device和driver，device和driver本来是不相关的东西，只因为bus的存在，才被联系到了一起。本节就来看看设备驱动模型中起枢纽作用的bus。本节的头文件在include/linux/device.h和drivers/base/base.h，实现代码主要在bus.c中。因为在bus中有很多代码时为了device找到driver或者driver找到dev

2016-06-19 10:45:12 471

转载 linux下bus、devices和platform的基础模型

一、kobject的定义:kobject是Linux2.6引入的设备管理机制,在内核中由struct kobject结构表示,这个结构使所有设备在底层都具有统一的接口.kobject提供了基本的对象管理能力,是构成Linux2.6设备模型的核心结构,它与sysfs文件系统紧密联系,每个在内核中注册kobject对象都对应与sysfs文件系统中的一个目录;kobject--->sysfs.dir

2016-06-15 09:58:23 3136

转载 platform总线注册过程及platform_driver与platform_device的匹配

我们知道，按platform结构写驱动，我们只需注册platform_device和platform_driver而不需要我们自己去注册platform总线，因为系统启动就有那条总线，那么它是怎么得到的呢？这里进行具体跟踪一下：start_kernel——>rest_init——>kernel_thread(这个线程创建很重要)——>kernel_init——>do_basic_setup

2016-06-15 09:51:07 823

转载 LINUX设备驱动之platform总线

阅读本文之前，如果你对设备驱动模型还不了解，请先阅读本站设备驱动模型相关文章。Platform总线是kernel中的一种虚拟总线，2.6版本很多驱动都用它来实现。一．Platform初始化系统启动时初始化时创建了platform_bus设备和platform_bus_type总线：内核初始化函数kernel_init()中调用了do_basic_setup() ，该函数中调用dri

2016-06-15 07:38:17 1010

转载 Linux--内核Uevent事件机制与 Input子系统

一、Uevent机制1.前提摘要（1）Sysfs文件系统内核设备模型主要的模块和用户之间能看到的相关部分就是sysfs文件系统了。内核在启动的时候会注册sysfs文件系统，并且在启动系统的初期。通过mount命令挂载sysfs文件系统到/sys挂载点。 Mount -t sysfs sysfs /sys

2016-06-15 07:36:50 2938

转载基数树(radix tree)

基数（radix）树Linux基数树（radix tree）是将指针与long整数键值相关联的机制，它存储有效率，并且可快速查询，用于指针与整数值的映射（如：IDR机制）、内存管理等。IDR（ID Radix）机制是将对象的身份鉴别号整数值ID与对象指针建立关联表，完成从ID与指针之间的相互转换。IDR机制使用radix树状结构作为由id进行索引获取指针的稀疏数组，通过使用位图

2016-06-06 10:01:47 2667

转载把块存放在页高速缓存中

一、概述 Linux支持的文件系统大多以块的形式组织文件，为了减少对物理块设备的访问，在文件以块的形式调入内存后，使用块高速缓存（buffer_cache)对它们进行管理。每个缓冲区由两部分组成，第一部分称为缓冲区首部，用数据结构buffer_head表示，第二部分是真正的缓冲区内容（即所存储的数据）。由于缓冲区首部不与数据区域相连，数据区域独立存储。因而在缓冲区首部中，有一个指向数据的指

2016-06-02 10:42:48 1494

华的专栏