1． 设备树概念
1．1．设备树感性认识
设备树（Device Tree），将这个词分开就是“设备”和“树”，描述设备树的文件叫做DTS（Device Tree Source），这个DTS 文件采用树形结构描述板级设备，比如CPU 数量、 内存基地址、IIC 接口上接了哪些设备、SPI 接口上接了哪些设备等等。设备树是树形数据结构，具有描述系统中设备的节点。每个节点都有描述所代表设备特征的键值对。每个节点只有一个父节点，而根节点则没有父节点。
1．2．DTS、DTB、DTC
DTS：设备树源码文件；DTB：将DTS编译后得到的二进制文件；DTC：DTS的编译工具，其源码在内核的scriptsdtc目录下。基于同样arm架构的CPU有很多，同一个CPU会制作很多配置不一的板子，如何正确的编译所选的板子的DTS文件呢？在内核的arch／arm／boot／dts／Makefile中：
dtb－＄（CONFIG＿ARCH＿XXX） ＋＝ xxx．dtb
dtb－＄（CONFIG＿ARCH＿XXX） ＋＝ xxx－sip．dtb
dtb－＄（CONFIG＿ARCH＿XXX） ＋＝ xxx．dtb
dtb－＄（CONFIG＿ARCH＿XXX） ＋＝ xxx．dtb
例如xxxx的开发板，只要设置CONFIG＿ARCH＿xxx＝y，所有用到这颗SOC的DTS都会编译成DTB。如果后续还用到了这颗SOC设计的开发板，只要新建一个DTS文件，并将对应名称的DTB文件名加到dtb－＄（CONFIG＿ARCH＿xxx）中，在编译设备树时就会将DTS编译为二进制的DTB文件。
1．3．Device Tree语法
以下语法分析均以xxx．dts为例。
1．3．1． dtsi头文件
设备树的头文件扩展名为 ．dtsi。以xxx．dts为例，其包含以下头文件。
＃include ＂skeleton．dtsi＂
＃include xxx．h＂
＃include ＂xxx－clocks．dtsi＂
＃include ＂xxx－pinctrl．dtsi＂
＃include ＂xxx－camera．dtsi＂
需要注意的是．dts文件不但可以引用．dtsi文件，还可以引用．h文件和其他的．dts文件。Q1：每一个．dtsi和．dts都有自己的根节点，但是一个设备树文件只允许有一个根节点，DTC如何处理？将根节点合并，保留最后一级的根节点。包含的头文件内容会被展开，展开的位置在／memory和／cpus之间。（存疑，只用xxx．dts编译过）Q2：如果包含过程中有重复的compatible，DTC怎么处理？编译时不会报错，会生成两个compatible属性一样的节点。
1．3．2． 设备节点
设备树中的每一个节点都按照以下格式命名：
node－name＠unit－address
node－name表示节点名称，它的长度范围应该是1～31个字符，可以由以下的字符组成：
字符说明0～9数字a－z小写字母A－Z大写字母，逗号（英文）．句号（英文）＿下划线（英文）＋加号－减号
表 2－1节点名称的有效字符
节点名称应以较低或大写字符开头，并应描述设备的一般类别。节点的单位地址特定于节点所在的总线类型。它由表2－1中字符集中的一个或多个ASCII字符组成。单位地址必须与节点的reg属性中指定的第一个地址匹配。如果节点没有reg属性，则必须省略＠unit－address，并且单独使用节点名称将节点与树中相同级别的其他节点区分开来。对于reg格式和单位地址，特定总线的绑定可能会指定附加更具体的要求。根节点没有节点名称或单位地址。它由正斜杠（／）标识。
图 2－1节点名称示例
在图2－1中，节点名称为cpu的两个节点通过uint－address 0和1区分；节点名称为ethernet的两个节点通过uint－address fe002000和fe003000区分。在设备树中经常会看到以下设备名称：
watchdog： watchdog＠04009800
冒号前的是节点标签（label），冒号后是节点名称。引入label的目的是方便访问节点，可以直接通过＆label来访问这个节点。比如上述节点就可以使用＆watchdog来访问。
1．3．2．1． 通用名称建议
节点的名称应该有些通用，反映设备的功能，而不是其精确的编程模型。如适用，名称应为以下选择之一：
• adc • accelerometer
• atm • audio－codec
• audio－controller • backlight：
• bluetooth • bus
• cache－controller • camera
• can • charger
• clock： • clock－controller
• compact－flash • cpu
• cpus • crypto
• disk • display
• dma－controller • dsp
• eeprom • efuse：
• mdio • memory
• memory－controller • mmc
• mmc－slot • mouse
• nand－controller • nvram
• oscillator • parallel
• pc－card • pci
• pcie • phy
• pinctrl • pmic
• pmu • port
• ports • pwm
1．3．2．2． 路径名称
通过指定从根节点到所需节点的完整路径（通过所有子节点），可以唯一识别devicetree中的节点。指定设备路径的约定是：
／node－name－1／node－name－2／．．．／node－name－N
例如，在图2－1中，到cpu＃1的设备路径为：
／cpus／cpu＠1
／为根节点，在保证完整路径明确的前提下，可以省略uint－address。
1．3．3． 属性
设备树中的每个节点都有描述节点特性的属性。属性由名称和值组成。
1．3．3．1． 属性名称
属性名称的长度范围应该是1～31个字符，可以由以下的字符组成：
字符说明0～9数字a－z小写字母A－Z大写字母，逗号（英文）．句号（英文）＿下划线（英文）＋加号？问号（英文）＃＃号（hash）
非标准属性名称应指定唯一的字符串前缀，例如股票代号，用于标识定义该属性的公司或组织的名称。示例：
xxx，pin－function ＝ ＜6＞；
fsl，channel－fifo－len
linux，network－index
ibm，ppc－interrupt－server＃s
1．3．3．2． 属性值
属性值是包含与属性关联的信息的零或多个字节的数组。
数值描述、值为空，用于描述bool信息。个人理解类似于flag参数、32位整数，采用big－endian格式。示例：32位值0x11223344将在内存中表示为：地址 11 地址 ＋ 1 22 地址 ＋ 2 33 地址 ＋ 3 44、表示采用big－endian格式的64位整数。包括两个值，其中第一个值包含整数的最有效位，第二个值包含最小有效位。例如：64位值0x1122334455667788将表示为两个单元格：＜0x11223344 0x55667788＞。、格式特定于属性，参见属性定义。、字符串可打印且以空值（）结尾。、一个值。phandle值是引用设备树中另一个节点的方法。可被引用的任何节点都用唯一的定义了phandle属性数值。该数字用于带有phandle值类型的属性值。、串联在一起的值列表。
big－endian和little－endian（大小端）：big－endian：是指低地址端存放高位字节；little－endian：是指高地址端存放低位字节；
1．3．3．3． 标准属性Compatible（兼容）属性名称兼容值值类型＜stringlist＞描述兼容属性值由定义设备特定编程模型的一个或多个字符串组成。客户端程序应使用此字符串列表选择设备驱动程序。该属性值包含一个从最特定到最通用的null终止字符串的串联列表。它们允许设备表达其与一系列类似设备的兼容性，可能允许单个设备驱动器与几个设备匹配。推荐的格式是“制造商，型号”，其中制造商是描述制造商名称的字符串（如股票代号）。
示例：
compatible ＝“fsl，mpc8641”，“ns16550”；
在此示例中，操作系统将首先尝试查找支持fsl，mpc8641－uartmpc8641的设备驱动程序。如果找不到驱动程序，然后，它将尝试定位受支持的更通用的ns16550设备类型驱动程序 。
一般驱动程序文件都会有个OF匹配表，此匹配表保存着一些compatible值，如果设备节点的 compatible属性值和OF匹配表中的任何一个值相等，那么就表示设备可以使用这驱动。比如在文件drvier／misc／memctrl．c中：
static struct of＿device＿id＿xxx＿memctrl＿of＿match［］ ＝ ｛
｛ ．compatible ＝ ＂xxxx，memctrl＂， ｝，
｛｝，
｝；
对应的，在arch／arm／boot／dts／xxx．dts中有：
memctrl： memctrl ｛
compatible ＝ ＂xxxx，memctrl＂；
reg ＝ ＜0x0121B000 0x1044＞；
clocks ＝ ＜＆sdram＿bandw＿clk＞， ＜＆mem＿axi＿clk＞；
clock－names ＝ ＂sdram＿bandwidth＿clk＂， ＂mem＿axi＿clk＂；
interrupts ＝ ＜GIC＿SPI INT＿SDRAM IRQ＿TYPE＿LEVEL＿HIGH＞；
interrupt－controller；
＃interrupt－cells ＝ ＜1＞；
｝；
Model（型号）属性名称模型值值类型
描述指定设备的制造商型号。推荐的格式为：“制造商，型号”，其中制造商是描述制造商名称的字符串（如股票代号）。
示例：
model ＝“fsl，MPC8349EMITX”；
Phandle（pointer handle）属性名称pointer handle值值类型
描述phandle属性指定设备树中唯一节点的数字标识符。phandle属性值被需要引用与该属性关联的节点的其他节点使用。
示例：
pic＠10000000 ｛
phandle ＝ ＜1＞；
interrupt－controller；
｝；
定义了1的phandle值。另一个设备节点可以引用phandle值为1的pic节点：
another－device－node ｛
interrupt－parent ＝ ＜1＞；
｝；
Status属性名称状态值值类型＜string＞描述状态属性指示设备的操作状态，其有效值如下：＂okay＂：指示设备可运行。＂disabled＂：表明设备目前尚未运行，但未来可能会运行（例如，未插入或关闭某物）。＂fail＂：表示设备无法运行，在设备中检测到严重错误，如果不进行维修就不太可能运行＂fail－sss＂：表示设备无法运行，在设备中检测到严重错误，如果不进行维修就不太可能运行，sss部分特定于设备，并指示检测到的错误情况。＃address－cells and ＃size－cells属性名称＃address－cells，＃size－cells值类型＜u32＞描述＃address－cells和＃size－cells属性可用于设备树层次结构中包含子节点并描述如何解决子设备节点的任何设备节点。＃address－cells属性定义用于编码子节点的reg属性中地址字段的个单元格的数量。＃size－cells属性定义用于编码子节点的reg属性中大小字段的个单元格的数量。＃address－cells ＝ ＜1＞；
＃size－cells ＝ ＜0＞；
表示reg属性中有一个u32表示address，没有表示reg大小的数据，所以：reg ＝ ＜0x0＞； 即reg的起始地址为0x0，不描述其大小
＃address－cells ＝ ＜1＞；
＃size－cells ＝ ＜1＞；
表示reg属性中有一个u32表示address，有一个u32表示size，所以：reg ＝ ＜0x00000000 0x00040000＞； 即reg的起始地址为0x00000000，大小是0x00040000
Reg属性名称reg值类型＜prop－encoded－array＞ 编码为任意数量（地址、长度）对描述reg属性描述设备资源在其父总线定义的地址空间内的地址。这通常意味着内存映射IO寄存器块的偏移和长度，但在某些总线类型上可能有不同的含义。根节点定义的地址空间中的地址为cpu真实地址。该值是一个，由任意数量的地址和长度对组成，＜地址长度＞。指定地址和长度所需的单元格的数量是总线特定的，由设备节点父级中的＃address－cells和＃size－cells属性指定。如果父节点为＃size－cells单元格指定值0，则应忽略reg值中的长度字段。
示例：假设系统芯片中的设备包含两个寄存器块，SOC中偏移0x3000的32字节块和偏移0xFE00的256字节块。reg属性的编码如下（假设＃address－cells和＃size－cells值为1）：
reg＝＜0x3000 0x20 0xFE00 0x100＞；
virtual－reg属性名称virtual－reg值类型＜u32＞描述virtual－reg属性指定一个有效地址，该地址映射到设备节点的reg属性中指定的第一个物理地址。此属性使引导程序能够为客户端程序提供已设置的虚拟到物理映射。Ranges属性名称range值类型＜empty＞或编码为任意数量的（子总线地址、父总线地址、长度）三联体描述range属性提供了一种在总线地址空间（子地址空间）和总线节点父地址空间（父地址空间）之间定义映射或转换的方法。range属性值的格式是任意数量的三联体（子总线地址、父总线地址、长度）：1．子总线地址是子总线地址空间内的物理地址。表示地址的单元格数取决于总线，可以通过此节点（出现range属性的节点）的＃address－cells确定。2． 父总线地址是父总线地址空间中的物理地址。表示父地址的单元格数取决于总线，可以通过定义父地址空间的节点的＃address－cells属性确定。3． 长度指定子地址空间中范围的大小。表示大小的单元格数可以根据该节点（出现range属性的节点）的＃size－cells确定。如果属性用值定义，则它指定父地址和子地址空间相同，并且不需要地址转换。如果总线节点中不存在该属性，则假设节点的子节点和父地址空间之间不存在映射。
示例：
soc ｛
compatible ＝ ＂simple－bus＂；
＃address－cells ＝ ＜1＞；
＃size－cells ＝ ＜1＞；
ranges ＝ ＜0x0 0xe0000000 0x00100000＞；
serial ｛
device＿type ＝ ＂serial＂；
compatible ＝ ＂ns16550＂；
reg ＝ ＜0x4600 0x100＞；
clock－frequency ＝ ＜0＞；
interrupts ＝ ＜0xA 0x8＞；
interrupt－parent ＝ ＜＆ipic＞；
｝；
｝；
soc节点指定了＜0x0 0xe0000000 0x00100000＞；此属性值指定对于1024KB范围的地址空间，在物理0x0处寻址的子节点映射到物理0xe0000000的父地址。通过这种映射，串行设备节点可以通过0xe0004600地址的加载或存储、0x4600（在注册表中指定）的偏移量以及范围中指定的0xe0000000映射寻址。
dma－ranges属性名称dma－ranges值类型＜empty＞或编码为任意数量的（子总线地址、父总线地址、长度）三联体描述dma－range属性用于描述存储器映射总线的直接存储器访问（dma）结构，其设备树父级可以从总线的dma操作访问。它提供了一种定义总线物理地址空间与总线父级物理地址空间之间映射或转换的方法。dma－range属性的值的格式是任意数量的（子总线地址、母线地址、长度）。指定的每个三联体描述连续DMA地址范围。1． 子总线地址是子总线地址空间内的物理地址。表示地址的单元格数取决于总线，可以通过该节点（dma－range属性出现的节点）的＃address－cells地址单元格确定。2． 父总线地址是父总线地址空间中的物理地址。表示父地址的单元格数取决于总线，可以通过定义父地址空间的节点的＃address－cells属性确定。3． 长度指定子地址空间中范围的大小。表示大小的单元格数量可以根据该节点（dma－range属性出现的节点）的＃size－cells确定。Name（已弃用）属性名称name值类型＜string＞描述name属性用于记录节点名字，name属性已经被弃用 ，不推荐使用 name属性，一些老的设备树文件可能会使用此属性。device＿type属性名称device＿type值类型＜string＞描述由于DTS没有FCode，因此不建议使用该属性。只能用于在cpu节点和memory节点中，以便与IEEE 1275衍生设备兼容。1．3．4． 基本设备节点类型
所有设备树文件均要包含一个根文件，并且所有设备树文件均应在根节点下存在以下节点：
1个／cpus节点至少一个／memory节点
使用说明：R ＝ 必需，O ＝ 可选，OR ＝ 可选但推荐，SD ＝ 参见定义，所有其他的标准属性均可接受，但可选
1．3．4．1． Root node
devicetree有一个单独的根节点，所有其他设备节点都是它的后代。根节点的完整路径为／。
属性名称使用说明类型定义＃address－cellsR＜u32＞root子节点的reg property地址格式。＃size－cellsR＜u32＞root子节点的reg property大小格式。modelR＜string＞指定唯一标识。系统板型号。推荐格式为“制造商，型号”compatibleR＜stringlist＞指定平台体系结构列表。该平台兼容。这一建议可供操作系统在选择平台特定代码时使用。1．3．4．2． ／aliases节点
设备树文件可能具有一个别名节点（／aliases），该节点定义一个或多个别名属性。别名节点应位于设备树的根节点，并且具有节点名称／别名。／aliases节点的每个属性都定义了一个别名。属性名称指定别名。属性值指定设备树中节点的完整路径。例如，属性serial0 ＝ ＂／simple－bus＠fe000000／serial＠llc500＂定义了别名serial0。别名的命名规则如下：
字符描述0－9数字a－z小写字母－破折号1．3．4．3． ／memory节点
所有设备树都需要内存设备节点，并描述系统的物理内存布局。如果系统具有多个范围的内存，则可以创建多个内存节点，或者可以在单个内存节点的reg属性中指定范围。
／memory节点的属性要求如下：
属性名称使用说明类型定义device＿typeRO＜string＞regR＜prop－encoded－array＞由任意数量的地址和大小对组成，它们指定内存范围的物理地址和大小initial－mapped－areaO＜prop－encoded－array＞指定”初始映射区域”的地址和大小，是一个由三元组组成的属性编码数组（有效地址、物理地址、大小）。有效和物理地址均应为64位（值），大小应为32位（值）
在xxx．dts中
memory ｛
reg ＝ ＜0x40000000 0x10000000＞； 起始地址0x40000000 长度0x10000000（32MB）
｝；
1．3．4．4． ／chosen 节点
／chosen 节点不代表系统中的实际设备，而是描述了在运行时由系统固件选择或指定的参数。它应该是根节点的子节点。
属性名称使用说明类型定义bootargsO＜string＞指定程序的启动参数。如果不需要引导参数，则该值可能为空字符串stdout－pathO＜string＞指定到表示用于引导控制台输出的设备的节点的完整路径。如果包含’：’，则它将终止路径。该值可以是别名。stdin－pathO＜string＞指定到表示用于引导控制台输入的设备的节点的完整路径。如果包含’：’，则它将终止路径。该值可以是别名。
示例：
chosen ｛
bootargs ＝ ＂root＝／dev／nfs rw nfsroot＝192．168．1．1 console＝ttyS0，115200＂；
｝；
1．3．4．5． ／cpus节点属性
所有设备树均需要／cpus／cpu节点。它并不代表系统中的真实设备，而是作为代表系统cpu的子cpu节点的容器。
属性名称使用说明类型定义device＿typeR＜string＞值应为“cpu”regR＜prop－encoded－array＞它为CPU节点表示的CPU／线程定义了唯一的CPU／线程ID。如果CPU支持多线程，则reg是一个数组，每个线程具有一个元素。clock－frequencyR＜prop－encoded－array＞以Hz为单位指定CPU的当前时钟速度，格式可以是，或timebase－frequencyR＜prop－encoded－array＞指定更新时基的当前频率statusSD＜string＞此属性应存在于对称多进程（SMP）CPU的节点中 配置。”okay”：CPU正在运行；”disable”：CPU处于静止状态。1．3．5． 中断映射
在设备树中，存在逻辑中断树，该逻辑中断树表示平台硬件中断的层次结构和路由。在设备树中，使用interrupt－parent属性表示中断源与中断控制器的物理连线。代表产生中断的设备节点包含一个中断父属性，该属性具有一个虚拟值，指向给设备的中断所路由到的设备（通常是中断控制器）。
如果产生中断的设备不具有中断父属性，则假定其中断父节点为其设备父节点。每个中断产生设备都包含一个中断属性，该属性的值描述该设备的一个或多个中断源。每个源都用称为中断描述符表示。中断描述符的格式和含义是特定于中断域的，即，取决于中断域根节点上节点的属性。中断域的根使用＃interrupt－cells属性定义对中断描述符进行编码所需的值数量。
中断域是解释中断描述符的上下文。中断域的根可以是中断控制器（interrupt controller）或中断连接器（interrupt nexus）：
中断控制器是物理设备，需要一个驱动程序来处理通过它路由的中断。它还可能级联到另一个中断域。中断控制器由设备树中该节点上的interrupt－controller指定。中断连接器定义了一个中断域和另一个中断域之间的转换。翻译基于特定领域和总线的信息。使用interrupt－map属性在域之间进行转换。例如，PCI控制器设备节点可以是一个中断连接器，定义从PCI中断命名空间（INTA、INTB等）到具有中断请求（IRQ）编号的中断控制器的转换。
1．3．5．1． Interrupts属性名称interrupts值类型＜prop－encoded－array＞编码为任意数量的中断描述符描述设备节点的中断属性定义设备生成的中断。interrupts属性的值由任意数量的中断描述符组成。中断描述符的格式由中断域根定义。
示例：
interrupts ＝ ＜GIC＿SPI INT＿DMA IRQ＿TYPE＿LEVEL＿HIGH＞；
1．3．5．2． interrupt－parent属性名称interrupt－parent值类型＜phandle＞描述由于中断树中节点的层次结构可能与device tree不匹配，因此interrupt－parent属性可用于明确中断父级的定义。该值是中断父级的phandle。如果设备缺少此属性，则假定其中断父级为其设备树父级。
示例：
interrupt－parent ＝ ＜＆gpe＞；
1．3．5．3． interrupts－extended属性名称interrupts－extended值类型＜phandle＞描述扩展的中断属性列出了设备产生的中断。当设备连接到多个中断控制器时，应该使用interrupts－extended代替interrupts，因为它会在每一个中断描述符编码一个父代phandle
示例：
interrupts－extended ＝ ＜＆pic 0xA 8＞， ＜＆gic 0xda＞；
1．3．5．4． ＃interrupt－cells属性名称＃interrupt－cells值类型＜u32＞描述＃interrupt－cells属性定义对中断域的中断描述符进行编码所需的单元数量1．3．5．5． interrupt－controller属性名称interrupt－controller值类型＜empty＞描述中断控制器属性的存在将节点定义为中断控制器节点。1．4．Device Tree binary格式
Devicetree Blob （DTB）格式是Devicetree数据的平面二进制编码。它用来在软件程序之间交换设备数据。例如，在引导操作系统时，固件将向操作系统内核传递一个DTB。
DTB格式将devicetree数据编码为一个单一的、线性的、无指针的数据结构。它由一个小标题组成，接下来是三个大小可变的部分：内存保留块、结构块和字符串块这些应该按照这个顺序出现在扁平的devicetree中。
因此。当按地址加载到内存中时，设备树结构作为一个整体。将类似于图中的图表。
1．4．1． dt＿header
设备树的头部是由以下C结构体定义的。所有字段都是32位整数，以big－endian格式存储。
struct fdt＿header ｛
此字段应包含值0xd00dfeed（big－endian）
uint32＿t magic； magic word FDT＿MAGIC
此字段应包含设备数据结构的总大小（字节）。该大小应包含结构的所有部分：报头、内存预留块、结构块和字符串块，以及块之间或最终块之后的自由空间间隙。
uint32＿t totalsize； total size of DT block
此字段应包含结构块从标题开始的字节偏移
uint32＿t off＿dt＿struct； offset to structure
此字段应包含从标题开始的字符串块的字节偏移量
uint32＿t off＿dt＿strings； offset to strings
此字段应包含从标题开始的内存保留块的字节偏移量
uint32＿t off＿mem＿rsvmap； offset to memory reserve map
此字段应包含设备数据结构的版本
uint32＿t version； format version
此字段应包含设备所用版本向后兼容的最低版本数据结构
uint32＿t last＿comp＿version； last compatible version
version 2 fields below
此字段应包含系统引导CPU的物理ID。它应与设备树中CPU节点的reg属性中给定的物理ID相同
uint32＿t boot＿cpuid＿phys； Which physical CPU id we＇re booting on
version 3 fields below
此字段应包含字符串块部分的字节长度
uint32＿t size＿dt＿strings； size of the strings block
version 17 fields below
此字段应包含结构块部分的字节长度
uint32＿t size＿dt＿struct； size of the structure block
｝；
1．4．2． memory reservation block
内存保留块向客户端程序提供物理内存中被保留的区域的列表，这些内存不用于一般的内存分配，目的是保护重要的数据结构不被客户端程序覆盖。这个区域包括了若干的reserve memory描述符。每个reserve memory描述符是由address和size组成。其中address和size都是用U64来描述：
struct fdt＿reserve＿entry ｛
uint64＿t address；
uint64＿t size；
｝；
1．4．3． Structure block
结构块描述了设备树本身的结构和内容。它由若干的分片组成，每个分片开始位置都是保存了令牌（token），以此来描述该分片的属性和内容。
FDT＿BEGIN＿NODE （0x00000001）：该token描述了一个node的开始位置，紧挨着该token的就是node name（包括unit address）FDT＿END＿NODE （0x00000002）：该token描述了一个node的结束位置FDT＿PROP （0x00000003）：该token描述了一个property的开始位置，该token之后是两个u32的数据。它们之后就是长度为len的具体的属性值数据。struct ｛
uint32＿t len； 表示该property value data的size。
uint32＿t nameoff； 表示该属性字符串在device tree strings block的偏移值
｝
FDT＿NOP （0x00000004）：被解析设备树的程序忽略，可用于覆盖其他属性，以删除它FDT＿END （0x00000009）：标记结构块的结束所以，一个DTB的结构块可能如下：（optionally） any number of FDT＿NOP tokens
FDT＿BEGIN＿NODE token：
－－node’s name
－－paddings
For each property of the node：
－－FDT＿NOP（optionally）
－－FDT＿PROP token
－－property
all child nodes in this format
（optionally） any number of FDT＿NOP tokens
FDT＿END＿NODE token
1．4．4． Strings Block
定义了各个node中使用的属性的字符串表。由于很多属性会出现在多个node中，因此，所有的属性字符串组成了一个string block。这样可以压缩DTB的size。
1．5．Linux解析设备树
设备树描述了设备的详细信息，这些信息包括数字类型的、字符串类型的、数组类型的，我们在编写驱动时需要去获取这些信息。Linux内核提供一系列以of＿开头的函数来获取设备树信息，这些函数的原型都定义在include／linux／of．h中。设备以节点的形式挂在设备树上，Linux内核使用device＿node结构体来描述一个节点，其定义在include／linux／of．h中：
struct device＿node ｛
const char ＊name； device node name
const char ＊type； 对应device＿type的属性
phandle phandle； 对应该节点的phandle属性
const char ＊full＿name； 从“／”开始的，表示该node的full path
Struct property ＊properties； 该节点的属性列表
如果需要删除某些属性，kernel并非真的删除，而是挂入到deadprops的列表
struct property ＊deadprops； removed properties
parent、child以及sibling将所有的device node连接起来
Struct device＿node ＊parent；
Struct device＿node ＊child；
Struct device＿node ＊sibling；
通过该指针可以获取相同类型的下一个node
Struct device＿node ＊next； next device of same type
通过该指针可以获取node global list下一个node
struct device＿node ＊allnext； next in list of all nodes
struct kobject kobj；
unsigned long ＿flags；
void ＊data；
＃if defined（CONFIG＿SPARC）
const char ＊path＿component＿name；
unsigned int unique＿id；
struct of＿irq＿controller ＊irq＿trans；
＃endif
｝；
1．5．1． 查找节点的 OF函数1．5．1．1． of＿find＿node＿by＿name
功能 ：Find a node by its ＂name＂ property函数
struct device＿node ＊of＿find＿node＿by＿name（struct device＿node ＊from，
const char ＊name）
参数 ：
＠from：开始查找的节点，如果为NULL表示从根节点开始查找整个设备树。
＠name：：要查找的节点名字。
返回值： 找到的节点，如果为NULL表示查找失败。
1．5．1．2． of＿find＿node＿by＿path
功能 ：Find a node matching a full OF path函数 ：
struct device＿node ＊of＿find＿node＿by＿path（const char ＊path）
参数 ：＠path： 完整的匹配路径返回值 ：找到的节点，如果为NULL表示查找失败。
1．5．1．3． of＿find＿node＿by＿type
功能 Find a node by its ＂device＿type＂ property函数
struct device＿node ＊of＿find＿node＿by＿type（struct device＿node ＊from，
const char ＊type）
参数
＠from：开始查找的节点，如果为NULL表示从根节点开始查找整个设备树
＠type： 要查找的节点类型
返回值 找到的节点，如果为NULL表示查找失败。
1．5．1．4． of＿find＿compatible＿node
功能 通过device＿type和compatible查找指定节点函数
struct device＿node ＊of＿find＿compatible＿node（struct device＿node ＊from，const char ＊type， const char ＊compatible）
参数
＠from：开始查找的节点，如果为NULL表示从根节点开始查找整个设备树
＠type： 要查找的节点device＿type属性
＠compatible：节点的compatible属性列表
返回值 找到的节点，如果为NULL表示查找失败。
1．5．1．5． of＿find＿node＿with＿property
功能 通过属性名查找指定节点函数
struct device＿node ＊of＿find＿node＿with＿property（struct device＿node ＊from，const char ＊prop＿name）
参数
＠from：开始查找的节点，如果为NULL表示从根节点开始查找整个设备树
＠type： 要查找的节点属性名称
返回值 找到的节点，如果为NULL表示查找失败。
1．5．2． 查找父 ／子节点的 OF函数1．5．2．1． of＿get＿parent
功能 函数用于获取指定节点的父节点（如果有父节点的话 ）函数
struct device＿node ＊of＿get＿parent（const struct device＿node ＊node）
参数
＠node：要查找父节点的节点
返回值 找到的父节点
1．5．2．2． of＿get＿next＿available＿child
功能 获取子节点，并跳过status ＝ ＂disabled＂的节点函数
struct device＿node ＊of＿get＿next＿available＿child（const struct device＿node ＊node，struct device＿node ＊prev）
参数
＠node： 父节点
＠prev：当前父节点的上一个子节点， 如果为空，则获取第一个子节点
返回值 找到的子节点
1．5．3． 提取属性值的 OF函数
Linux内核使用struct property来保存节点的属性，其定义在／include／linux／of．h中：
struct property ｛
char ＊name； 属性的名称
int length； 属性的长度
void ＊value； 属性的值
struct property ＊next； 下一个属性
unsigned long ＿flags；
unsigned int unique＿id；
struct bin＿attribute attr；
｝；
1．5．3．1． of＿find＿property
功能 寻找指定的属性函数
struct property ＊of＿find＿property（const struct device＿node ＊np，
const char ＊name，
int ＊lenp）
参数
＠np： 设备节点
＠name：属性名称
＠lenp：属性的字节数
返回值 找到的属性
1．5．3．2． 读取属性中u8、u16、u32和u64类型的数组数据
当设置sz为1时，就是读取一个数据，Linux内核也是这么封装的。
int of＿property＿read＿u8＿array（const struct device＿node ＊np，
const char ＊propname， u8 ＊out＿values， size＿t sz）
int of＿property＿read＿u16＿array（const struct device＿node ＊np，
const char ＊propname， u16 ＊out＿values， size＿t sz）
int of＿property＿read＿u32＿array（const struct device＿node ＊np，
const char ＊propname， u32 ＊out＿values，size＿t sz）
int of＿property＿read＿u64（const struct device＿node ＊np， const char ＊propname，
u64 ＊out＿value）
1．5．3．3． of＿property＿read＿string
功能 找到并读取属性字符串函数
int of＿property＿read＿string（struct device＿node ＊np， const char ＊propname，const char ＊＊out＿string）
参数
＠np： 设备节点
＠propname：属性名称
＠out＿string：读取的字符串
返回值
0：读取成功
－EINVAL：属性不存在
－ENODATA：属性没有这个值
－EILSEQ：字符串不是以空字符’’结尾
2． 设备树解析流程
2．1．内核启动并获取设备树
在uboot引导内核的时候，会将设备树在物理内存中的物理起始内存地址传递给Linux内核，然后Linux内核在unflattern＿device＿tree中解析设备镜像，并利用扫描到的信息创建由device node构成的链表，全局变量of＿allnodes指向链表的根节点，设备树的每一个节点都由一个struct device＿node与之对应。unflatten＿device＿tree的意思是解开设备树，在这个函数里调用了＿＿unflatten＿device＿tree这一函数：
＊
＊ ＿＿unflatten＿device＿tree － create tree of device＿nodes from flat blob
＊
＊ unflattens a device－tree， creating the
＊ tree of struct device＿node． It also fills the ＂name＂ and ＂type＂
＊ pointers of the nodes so the normal device－tree walking functions
＊ can be used．
＊ ＠blob： The blob to expand
＊ ＠mynodes： The device＿node tree created by the call
＊ ＠dt＿alloc： An allocator that provides a virtual address to memory
＊ for the resulting tree
static void ＿＿unflatten＿device＿tree（struct boot＿param＿header ＊blob，
struct device＿node ＊＊mynodes，
void ＊ （＊dt＿alloc）（u64 size， u64 align））
所以，现在为止，我们得到了一个名为of＿allnodes的struct ＊device＿node，它指向了设备树展开后的device＿node树，后续的操作都是基于device＿node树。
2．2．创建platform＿device
内核从启动到创建设备的过程大致如下：在do＿initcalls中会传递level给do＿initcall＿level来调用不同层次的初始化函数，level的对应关系见linux－3．10／include／linux／init．h 第196行。在这个初始化过程中，会调用一个customize＿machine的函数。
2．3．Platform driver注册流程
此节分析Platform driver的注册流程，以memctrl驱动的注册为例分析。关于系统调用驱动初始化函数的流程分析，参考自动初始化机制章节。本章节分析从设备驱动文件的xxx＿init函数开始分析。
2．3．1． struct platform＿driver
platform＿driver是在device＿driver之上的一层封装，其结构如下：
struct platform＿driver ｛
int （＊probe）（struct platform＿device ＊）； 探测函数
int （＊remove）（struct platform＿device ＊）； 驱动卸载时执行
void （＊shutdown）（struct platform＿device ＊）； 关机时执行函数
int （＊suspend）（struct platform＿device ＊， pm＿message＿t state）； 挂起函数
int （＊resume）（struct platform＿device ＊）； 恢复函数
struct device＿driver driver； 管理的driver对象
const struct platform＿device＿id ＊id＿table； 匹配时使用
｝；
2．3．2． struct device＿driver
struct device＿driver是系统提供的基本驱动结构：
struct device＿driver ｛
const char ＊name； 驱动名称
struct bus＿type ＊bus； 所属总线
struct module ＊owner； 模块拥有者
const char ＊mod＿name； 内建的模块使用
bool suppress＿bind＿attrs； 是否绑定到sysfs
const struct of＿device＿id ＊of＿match＿table； 设备树匹配表
const struct acpi＿device＿id ＊acpi＿match＿table； ACPI匹配表
int （＊probe） （struct device ＊dev）； 探测设备
int （＊remove） （struct device ＊dev）； 与设备脱离时调用
void （＊shutdown） （struct device ＊dev）； 在关机时关闭设备
int （＊suspend） （struct device ＊dev， pm＿message＿t state）； 使设备进入睡眠模式调用
int （＊resume） （struct device ＊dev）； 唤醒设备时调用
const struct attribute＿group ＊＊groups； 自动创建的默认属性组
const struct dev＿pm＿ops ＊pm； 设备的功耗管理
struct driver＿private ＊p； 驱动的私有数据
｝；
2．3．3． platform＿driver＿register
Platform＿driver的注册接口是platform＿driver＿register，其定义如下：
int platform＿driver＿register（struct platform＿driver ＊drv）
｛
drv－＞driver．bus ＝ ＆platform＿bus＿type； 设置总线类型
if （drv－＞probe） 确认定义了probe函数
drv－＞driver．probe ＝ platform＿drv＿probe； 里面实际调用的是drv的probe函数
if （drv－＞remove）
drv－＞driver．remove ＝ platform＿drv＿remove；
if （drv－＞shutdown）
drv－＞driver．shutdown ＝ platform＿drv＿shutdown；
return driver＿register（＆drv－＞driver）；
｝
platform＿driver＿register接口是为注册总线驱动做一些准备工作，定义了总线类型，设置了driver的部分接口，最后driver＿register会向总线注册驱动
2．3．4． driver＿registerint driver＿register（struct device＿driver ＊drv）
｛
int ret；
struct device＿driver ＊other；
BUG＿ON（！drv－＞bus－＞p）；
if （（drv－＞bus－＞probe ＆＆ drv－＞probe） ｜｜
（drv－＞bus－＞remove ＆＆ drv－＞remove） ｜｜
（drv－＞bus－＞shutdown ＆＆ drv－＞shutdown））
printk（KERN＿WARNING ＂Driver ＇％s＇ needs updating － please use ＂
＂bus＿type methods＂， drv－＞name）；
other ＝ driver＿find（drv－＞name， drv－＞bus）； 检查驱动是否已经注册
if （other） ｛
printk（KERN＿ERR ＂Error： Driver ＇％s＇ is already registered， ＂
＂aborting．．．＂， drv－＞name）；
return －EBUSY；
｝
ret ＝ bus＿add＿driver（drv）； driver＿register的主要工作放在了这里
if （ret）
return ret；
ret ＝ driver＿add＿groups（drv， drv－＞groups）； 主要是在sysfs添加驱动属性
if （ret） ｛
bus＿remove＿driver（drv）；
return ret；
｝
kobject＿uevent（＆drv－＞p－＞kobj， KOBJ＿ADD）； 涉及到uevent，暂时不分析
return ret；
｝
2．3．5． bus＿add＿driver
由以上分析可知，驱动的注册，重点在bus＿add＿driver（）函数，它会向总线添加驱动：
Drivers／base／bus．c
int bus＿add＿driver（struct device＿driver ＊drv）
｛
struct bus＿type ＊bus；
struct driver＿private ＊priv； 包含与驱动相关的kobject和klist结构
int error ＝ 0；
bus ＝ bus＿get（drv－＞bus）； 获取设备所属的总线类型
if （！bus）
return －EINVAL；
pr＿debug（＂bus： ＇％s＇： add driver ％s＂， bus－＞name， drv－＞name）；
priv ＝ kzalloc（sizeof（＊priv）， GFP＿KERNEL）；
if （！priv） ｛
error ＝ －ENOMEM；
goto out＿put＿bus；
｝
klist＿init（＆priv－＞klist＿devices， NULL， NULL）；
priv－＞driver ＝ drv；
drv－＞p ＝ priv；
priv－＞kobj．kset ＝ bus－＞p－＞drivers＿kset；
error ＝ kobject＿init＿and＿add（＆priv－＞kobj， ＆driver＿ktype， NULL，
＂％s＂， drv－＞name）；
if （error）
goto out＿unregister；
klist＿add＿tail（＆priv－＞knode＿bus， ＆bus－＞p－＞klist＿drivers）；
if （drv－＞bus－＞p－＞drivers＿autoprobe） ｛ 如果设置了自动探测
error ＝ driver＿attach（drv）；
if （error）
goto out＿unregister；
｝
module＿add＿driver（drv－＞owner， drv）；
error ＝ driver＿create＿file（drv， ＆driver＿attr＿uevent）；
if （error） ｛
printk（KERN＿ERR ＂％s： uevent attr （％s） failed＂，
＿＿func＿＿， drv－＞name）；
｝
error ＝ driver＿add＿attrs（bus， drv）；
if （error） ｛
How the hell do we get out of this pickle？ Give up
printk（KERN＿ERR ＂％s： driver＿add＿attrs（％s） failed＂，
＿＿func＿＿， drv－＞name）；
｝
if （！drv－＞suppress＿bind＿attrs） ｛
error ＝ add＿bind＿files（drv）；
if （error） ｛
Ditto
printk（KERN＿ERR ＂％s： add＿bind＿files（％s） failed＂，
＿＿func＿＿， drv－＞name）；
｝
｝
return 0；
out＿unregister：
kobject＿put（＆priv－＞kobj）；
kfree（drv－＞p）；
drv－＞p ＝ NULL；
out＿put＿bus：
bus＿put（bus）；
return error；
｝
2．3．6． driver＿attach
driver＿attach会尝试绑定设备和驱动。编译总线上的所有设备，然驱动挨个尝试匹配，如果driver＿probe＿device（）返回0且＠dev－＞driver被设置，就代表找到了一对兼容的设备驱动。
int driver＿attach（struct device＿driver ＊drv）
｛
return bus＿for＿each＿dev（drv－＞bus， NULL， drv， ＿＿driver＿attach）；
｝
EXPORT＿SYMBOL＿GPL（driver＿attach）；
2．3．7． ＿＿driver＿attach
对于每一个总线的设备，driver＿attach都会调用＿＿driver＿attach来尝试与驱动匹配。
static int ＿＿driver＿attach（struct device ＊dev， void ＊data）
｛
struct device＿driver ＊drv ＝ data；
＊ Lock device and try to bind to it． We drop the error
＊ here and always return 0， because we need to keep trying
＊ to bind to devices and some drivers will return an error
＊ simply if it didn＇t support the device．
＊
＊ driver＿probe＿device（） will spit a warning if there
＊ is an error．
if （！driver＿match＿device（drv， dev）） 匹配设备和驱动，这里调用的是platform＿match
return 0；
if （dev－＞parent） Needed for USB
device＿lock（dev－＞parent）；
device＿lock（dev）； 设置互斥锁，防止其他进程访问设备资源
if （！dev－＞driver）
如果设备没有驱动，则为设备探测驱动，这个函数与注册设备调用的是同一个函数
driver＿probe＿device（drv， dev）；
device＿unlock（dev）；
if （dev－＞parent）
device＿unlock（dev－＞parent）；
return 0；
｝
driver＿probe＿device里调用really＿probe函数，并在really＿probe中调用驱动文件中的probe函数，对于memctrl驱动而言，就是xxxx＿memctrl＿probe函数。至此，platfprm driver就注册好了。
2．4．Platform Bus的匹配原则
由以上的代码分析得知，注册platform device时，会调用＿＿device＿attach －＞ driver＿match＿device，注册platform driver时，会调用＿＿driver＿attach －＞ driver＿match＿device，也就是说设备和驱动都会调用到这个函数：
static inline int driver＿match＿device（struct device＿driver ＊drv，
struct device ＊dev）
｛
return drv－＞bus－＞match ？ drv－＞bus－＞match（dev， drv） ： 1；
｝
drv－＞bus－＞match，这是驱动绑定的总线提供的匹配函数，这里注册的是platform总线设备，而platform总线的定义参考3．2．6 platform＿bus＿type。Platform对应的match函数为：platform＿match：
static int platform＿match（struct device ＊dev， struct device＿driver ＊drv）
｛
struct platform＿device ＊pdev ＝ to＿platform＿device（dev）；
struct platform＿driver ＊pdrv ＝ to＿platform＿driver（drv）；
Attempt an OF style match first
if （of＿driver＿match＿device（dev， drv））
return 1；
Then try ACPI style match
if （acpi＿driver＿match＿device（dev， drv））
return 1；
Then try to match against the id table
if （pdrv－＞id＿table）
return platform＿match＿id（pdrv－＞id＿table， pdev） ！＝ NULL；
fall－back to driver name match
return （strcmp（pdev－＞name， drv－＞name） ＝＝ 0）；
｝
2．4．1． of＿driver＿match＿device
根据驱动的of＿match＿table判断是否有驱动与之匹配。对memctrl驱动而言，其of＿match＿table如下：
static struct of＿device＿id xxxx＿memctrl＿of＿match［］ ＝ ｛
｛ ．compatible ＝ ＂xxxx，memctrl＂， ｝，
｛｝，
｝；
of＿driver＿match＿device的执行流程如下：
所以重点应该在＿＿of＿match＿node函数：
2．4．1．1． ＿＿of＿match＿nodestatic const struct of＿device＿id ＊＿＿of＿match＿node（const struct of＿device＿id ＊matches， const struct device＿node ＊node）
｛
if （！matches）
return NULL；
while （matches－＞name［0］ ｜｜ matches－＞type［0］ ｜｜ matches－＞compatible［0］） ｛
int match ＝ 1；
if （matches－＞name［0］） 查找名字
match ＆＝ node－＞name ＆＆ ！strcmp（matches－＞name， node－＞name）；
if （matches－＞type［0］） 查找类型
match ＆＝ node－＞type ＆＆ ！strcmp（matches－＞type， node－＞type）；
if （matches－＞compatible［0］） 查找属性，检测节点的compatible是否与驱动的一致
match ＆＝ ＿＿of＿device＿is＿compatible（node， matches－＞compatible）；
if （match）
return matches；
matches＋＋；
｝
return NULL；
｝
3． 使用设备资源
4． 自动初始化机制
4．1．编译到内核
4．1．1． module＿init宏展开
Linux中每一个模块都有一个module＿init函数，并且有且只有一个，其定义如下：
＊
＊ module＿init（） － driver initialization entry point
＊ ＠x： function to be run at kernel boot time or module insertion
＊
＊ module＿init（） will either be called during do＿initcalls（） （if
＊ builtin） or at module insertion time （if a module）． There can only
＊ be one per module．
＃define module＿init（x） ＿＿initcall（x）；
＿＿initcall（x）定义如下：
＃define ＿＿initcall（fn） device＿initcall（fn）
device＿initcall（fn）定义如下：
＃define device＿initcall（fn） ＿＿define＿initcall（fn， 6）
＿＿define＿initcall的定义如下：
initcalls are now grouped by functionality into separate
＊ subsections． Ordering inside the subsections is determined
＊ by link order．
＊ For backwards compatibility， initcall（） puts the call in
＊ the device init subsection．
＊
＊ The ｀id＇ arg to ＿＿define＿initcall（） is needed so that multiple initcalls
＊ can point at the same handler without causing duplicate－symbol build errors．
＃define ＿＿define＿initcall（fn， id）
static initcall＿t ＿＿initcall＿＃＃fn＃＃id ＿＿used
＿＿attribute＿＿（（＿＿section＿＿（＂．initcall＂ ＃id ＂．init＂））） ＝ fn
Initcalls现在按照功能分组到单独的子部分。子部分内部的顺序由链接顺序决定。为了向后兼容，initcall（）将调用放到device init小节中。需要定义initcall（）的’id’参数，以便多个initcall可以指向同一个处理程序，而不会导致重复符号构建错误。若不理解上述代码的用法，可以参考＿＿attribute＿＿的section用法和C语言宏定义中＃和＃＃的用法。所以将＿＿define＿initcall展开将会是下面的内容：
假设＿＿define＿initcall（led＿init， 6）
Static initcall＿t ＿＿initcall＿led＿init6 ＿＿used
＿＿attribute＿＿（（＿＿section＿＿（＂．initcall6．init＂））） ＝ led＿init
即是定义了一个类型为initcall＿t的函数指针变量＿＿initcall＿led＿init6，并赋值为led＿init，该变量在链接时会链接到section（．initcall6．init）。
4．1．2． 链接脚本
在linux3．10／arch／arm／kernel／vmlinux．lds．S中：
．．．．．．
SECTIONS line 54
｛
．．．．．．
．init．data ： ｛ line 202
＃ifndef CONFIG＿XIP＿KERNEL
INIT＿DATA
＃endif
INIT＿SETUP（16）
INIT＿CALLS
CON＿INITCALL
SECURITY＿INITCALL
INIT＿RAM＿FS
｝
．．．．．．
｝
在linux3．10／include／asm－generic／vmlinux．lds．h中：
＃define VMLINUX＿SYMBOL（x） ＿＿VMLINUX＿SYMBOL（x）
＃define ＿＿VMLINUX＿SYMBOL（x） x
．．．．．． line 664
＃define INIT＿CALLS＿LEVEL（level）
VMLINUX＿SYMBOL（＿＿initcall＃＃level＃＃＿start） ＝ ．；
＊（．initcall＃＃level＃＃．init）
＊（．initcall＃＃level＃＃s．init）
＃define INIT＿CALLS
VMLINUX＿SYMBOL（＿＿initcall＿start） ＝ ．；
＊（．initcallearly．init）
INIT＿CALLS＿LEVEL（0）
INIT＿CALLS＿LEVEL（1）
INIT＿CALLS＿LEVEL（2）
INIT＿CALLS＿LEVEL（3）
INIT＿CALLS＿LEVEL（4）
INIT＿CALLS＿LEVEL（5）
INIT＿CALLS＿LEVEL（rootfs）
INIT＿CALLS＿LEVEL（6）
INIT＿CALLS＿LEVEL（7）
VMLINUX＿SYMBOL（＿＿initcall＿end） ＝ ．；
．．．．．．
所以 INIT＿CALLS＿LEVEL（6）会展开为：
＿＿initcall6＿start ＝ ．； ＊（．initcall6．init） ＊（．initcall6s．init）
所以＿＿initcall＿led＿init6会链接到
section（．initcall6．init）
4．1．3． 初始化
内核启动流程为：
do＿initcall＿level的主要内容如下：
linux3．10／init／main．c line 744
static void ＿＿init do＿initcall＿level（int level）
｛
．．．．．
for （fn ＝ initcall＿levels［level］； fn ＜ initcall＿levels［level＋1］； fn＋＋）
do＿one＿initcall（＊fn）；
｝
由代码可知，内核会依次调用level段存储的初始化函数。比如对于模块来说level等于6。
4．2．动态加载的模块（．ko）4．2．1． Module＿init展开
如果设置为编译成动态加载的模块（．ko），module＿init的展开形式与编译到内核不一样。
Each module must use one module＿init（）．
＃define module＿init（initfn）
static inline initcall＿t ＿＿inittest（void） 检查定义的函数是否符合initcall＿t类型
｛ return initfn； ｝
int init＿module（void） ＿＿attribute＿＿（（alias（＃initfn）））；
alias属性是GCC的特有属性，将定义init＿module为函数initfn的别名，所以module＿init（initfn）的作用就是定义一个变量名 init＿module，其地址和initfn是一样的。
4．2．2． ＊mod．c文件
编译成module的模块都会自动产生一个＊．mod．c的文件，例如：
struct module ＿＿this＿module
＿＿attribute＿＿（（section（＂．gnu．linkonce．this＿module＂））） ＝ ｛
．name ＝ KBUILD＿MODNAME，
．init ＝ init＿module，
＃ifdef CONFIG＿MODULE＿UNLOAD
．exit ＝ cleanup＿module，
＃endif
．arch ＝ MODULE＿ARCH＿INIT，
｝；
即定义了一个类型为module的全局变量＿＿this＿module，其成员．init就是上文由module＿init定义的init＿module变量。并且＿＿this＿module会被链接到section（＂．gnu．linkonce．this＿module＂）。
4．2．3． 动态加载
insmod是busybox提供的用户层命令：路径busybox／modutils／ insmod．c
insmod＿main
bb＿init＿module
init＿module
路径busybox／modutils／modutils．c：
＃define init＿module（mod， len， opts） ．
syscall（＿＿NR＿init＿module， mod， len， opts）该系统调用对应内核层的sys＿init＿module函数
路径：kernel／module．c
SYSCALL＿DEFINE3（init＿module，…）
／／加载模块的ko文件，并解释各个section，重定位
mod ＝ load＿module（umod， len， uargs）；
／／查找section（＂．gnu．linkonce．this＿module＂）
modindex ＝ find＿sec（hdr， sechdrs， secstrings，＂．gnu．linkonce．this＿module＂）；
／／找到Hello＿module．mod．c定义的module数据结构
mod ＝ （void ＊）sechdrs［modindex］．sh＿addr；
if （mod－＞init ！＝ NULL）
ret ＝ do＿one＿initcall（mod－＞init）； ／／调用initfn．
4．3．＿＿attribute＿＿的section用法
＿＿define＿initcall使用了gcc的 ＿＿attribute＿＿众多属性中的section子项，其使用方式为：
＿＿attribute＿＿（（＿＿section＿＿（＂section＿name＂）））
其作用是将作用的函数或数据放入指定的名为”section＿name”的段。
4．4． C语言宏定义中＃和＃＃的用法4．4．1． 一般用法
我们使用＃把宏参数变为一个字符串。
＃define PRINT（FORMAT，VALUE）
printf（＂The value of＂＃VALUE＂is ＂ FORMAT＂＂，VALUE）
调用：printf（＂％d＂，x＋3）； －－＞ 打印：The value of x＋3 is 20
这是因为”The value of”＃VALUE”is ” FORMAT””实际上是包含了”The value of “，＃VALUE，”is “，FORMAT，”” 五部分字符串，其中VALUE和FORMAT被宏参数的实际值替换了。
用＃＃把两个宏参数贴合在一起
＃define ADD＿TO＿SUM（sum＿number，val） sum＃＃sum＿bumber＋＝（val）
调用：ADD＿TO＿SUM（2，100）； －－＞ 打印：sum2＋＝（100）
需要注意的是凡宏定义里有用＇＃＇或＇＃＃＇的地方宏参数是不会再展开。
4．4．2． ＇＃＇和＇＃＃＇的一些应用特例合并匿名变量名＃define ＿＿＿ANONYMOUS1（type， var， line） type var＃＃line
＃define ＿＿ANONYMOUS0（type， line） ＿＿＿ANONYMOUS1（type， ＿anonymous， line）
＃define ANONYMOUS（type） ＿＿ANONYMOUS0（type， ＿＿LINE＿＿）
例：ANONYMOUS（static int）； 即 static int ＿anonymous70； 70表示该行行号；第一层：ANONYMOUS（static int）； －－＞ ＿＿ANONYMOUS0（static int， LINE）；第二层： －－＞ ＿＿＿ANONYMOUS1（static int， ＿anonymous， 70）；第三层： －－＞ static int ＿anonymous70；即每次只能解开当前层的宏，所以＿＿LINE＿＿在第二层才能被解开；
填充结构＃define FILL（a） ｛a， ＃a｝
enum IDD｛OPEN， CLOSE｝；
typedef struct MSG｛
IDD id；
const char msg；
｝MSG；
MSG ＿msg［］ ＝ ｛FILL（OPEN）， FILL（CLOSE）｝；
相当于：
MSG ＿msg［］ ＝ ｛｛OPEN， OPEN｝，
｛CLOSE， CLOSE｝｝；
记录文件名＃define ＿GET＿FILE＿NAME（f） ＃f
＃define GET＿FILE＿NAME（f） ＿GET＿FILE＿NAME（f）
static char FILE＿NAME［］ ＝ GET＿FILE＿NAME（＿＿FILE＿＿）；
得到一个数值类型所对应的字符串缓冲大小＃define ＿TYPE＿BUF＿SIZE（type） sizeof ＃type
＃define TYPE＿BUF＿SIZE（type） ＿TYPE＿BUF＿SIZE（type）
char buf［TYPE＿BUF＿SIZE（INT＿MAX）］；
－－ char buf［＿TYPE＿BUF＿SIZE（0x7fffffff）］；
－－ char buf［sizeof 0x7fffffff］；
这里相当于：
char buf［11］；
－ END －
