有时system.map文件可以帮助我们理解内核编译，它记录了所有代码的运行地址。下面一起看看如何读懂它system.map内容格式为：线性地址 类型 符号具体内容如下： 00100000 A phys_startup_32c0100000 T startup_32c0100000 A _text                             注:表示

Linux内核的符号表位于两个部分。首先是内核的静态部分，也就是内核文件映像vmlinuz部分的符号表。还有一部分则是Linux可配置模块部分的符号表。前者对应于/proc/ksyms和System.map这两个文件。    前者是一个"proc文件"并且是在内核启动时创建的。实际上 它不是一个真实的文件；它只是内核数据的简单表示形式。然而，System.map却是文件系统上的一个真实文件。可

例1：#include linux/kernel.h>#include linux/module.h>#include linux/init.h>#include linux/fs.h>#include linux/string.h>#include linux/mm.h>#include linux/syscalls.h>#include asm/unistd.h

今天师兄问，linux内核模块之间如何进行通信？我才想起我之前也有这个疑问，只是当时不需要所以就没去关心了。晚上查了些资料，终于弄明白了些。这里的通信可以简单点理解，就是模块B如何调用A的函数，变量或者常量。为了简化，我设计一个模块A中的一个函数为printMSG，原型为int printMSG(int n);传入的参数n表示打印几遍一个固定的字符串。模块A(在helloworld基础上修改的

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

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

1. 前言工作队列(workqueue)的Linux内核中的定义的用来处理不是很紧急事件的回调方式处理方法.以下代码的linux内核版本为2.6.19.2, 源代码文件主要为kernel/workqueue.c.2. 数据结构/* include/linux/workqueue.h */// 工作节点结构struct work_struct {// 等

四、在内核里写i2c设备驱动的两种方式前文介绍了利用/dev/i2c-0在应用层完成对i2c设备的操作，但很多时候我们还是习惯为i2c设备在内核层编写驱动程序。目前内核支持两种编写i2c驱动程序的方式。下面分别介绍这两种方式的实现。这里分别称这两种方式为“Adapter方式（LEGACY）”和“Probe方式（new style）”。（1） Adapter方式（LEGACY

一、概述谈到在linux系统下编写I2C驱动，目前主要有两种方式，一种是把I2C设备当作一个普通的字符设备来处理，另一种是利用linux I2C驱动体系结构来完成。下面比较下这两种驱动。第一种方法的好处（对应第二种方法的劣势）有：        ●    思路比较直接，不需要花时间去了解linux内核中复杂的I2C子系统的操作方法。第一种方法问题（对应第二种方法的好处）有：

介绍了上面的几种基本宏后，对list_entry的理解就容易了。----------------list_entry()--------------------list_entry()宏，获取当前list_head链表节点所在的宿主结构项。第一个参数为当前list_head节点的指针，即指向宿主结构项的list_head成员。第二个参数是宿主数据结构的定义类型。第三个参数为宿主结构