fs/ext2/inode.c相关函数注释

用数组chain[4]描述四种不同的索引，即直接索引、一级间接索引、二级间接索引、三级间接索引。举例说明这个结构各个域的含义。如果文件内的块号为8，则不需要间接索引，所以只用chain[0]一个Indirect结构，p指向直接索引表下标为8处，即＆inode->u.ext2_i.i_data[8]；而key则持有该表项的内容，即文件块号所对应的设备上的块号（类似于逻辑页面号与物理页面号的对应关系）；bh为NULL，因为没有用于间接索引的块。如果文件内的块号为20，则需要一次间接索引，索引要用chian[0]和chain[1]两个表项。第一个表项chian[0] 中，指针bh仍为NULL，因为这一层没有用于间接索引的数据块；指针p指向＆inode->u.ext2_i.i_data[12]，即间接索引的表项；而key持有该项的内容，即对应设备的块号。chain[1]中的指针bh则指向进行间接索引的块所在的缓冲区，这个缓冲区的内容就是用作间接索引的一个整数数组，而p指向这个数组中下标为8处，而key则持有该项的内容。这样，根据具体索引的深度depth，数组chain[]中的最后一个元素，即chain[depth-1].key，总是持有目标数据块的物理块号。而从chain［］中第一个元素chain［0］到具体索引的最后一个元素chain［depth-1］，则提供了具体索引的整个路径，构成了一条索引链，这也是数据名chain的由来。

了解了以上基本内容后，我们来看ext2_get_block（）函数的具体实现代码：

·      首先调用ext2_block_to_path（）函数，根据文件内的逻辑块号iblock计算出这个数据块落在哪个索引区间，要采用几重索引（1表示直接）。如果返回值为0，表示出错，因为文件内块号与设备上块号之间至少也得有一次索引。出错的原因可能是文件内块号太大或为负值。

·      ext2_get_branch（）函数深化从ext2_block_to_path（）所取得的结果，而这合在一起基本上完成了从文件内块号到设备上块号的映射。从ext2_get_branch（）返回的值有两种可能。一是，如果顺利完成了映射则返回值为NULL。二是，如果在某一索引级发现索引表内的相应表项为0，则说明这个数据块原来并不存在，现在因为写操作而需要扩充文件的大小。此时，返回指向Indirect结构的指针，表示映射在此断裂。此外，如果映射的过程中出错，例如，读数据块失败，则通过err返回一个出错代码。

·      如果顺利完成了映射，就把所得结果填入缓冲区结构bh_result中，然后把映射过程中读入的缓冲区（用于间接索引）全部释放。

·      可是，如果ext2_get_branch（）返回一个非0指针，那就说明映射在某一索引级上断裂了。根据映射的深度和断裂的位置，这个数据块也许是个用于间接索引的数据块，也许是最终的数据块。不管怎样，此时都应该为相应的数据块分配空间。

·      要分配空间，首先应该确定从物理设备上何处读取目标块。根据分配算法，所分配的数据块应该与上一次已分配的数据块在设备上连续存放。为此目的，在ext2_inode_info结构中设置了两个域i_next_alloc_block和i_next_alloc_goal。前者用来记录下一次要分配的文件内块号，而后者则用来记录希望下一次能分配的设备上的块号。在正常情况下，对文件的扩充是顺序的，因此，每次所分配的文件内块号都与前一次的连续，而理想上来说，设备上的块号也同样连续，二者平行地向前推进。这种理想的“建议块号”就是由ext2_find_goal（）函数来找的。

·      设备上具体物理块的分配，以及文件内数据块与物理块之间映射的建立，都是调用ext2_alloc_branch（）函数完成的。调用之前，先要算出还有几级索引需要建立。

·      从ext2_alloc_branch（）返回以后，我们已经从设备上分配了所需的数据块，包括用于间接索引的中间数据块。但是，原先映射开始断开的最高层上所分配的数据块号只是记录了其Indirect结构中的key域，却并没有写入相应的索引表中。现在，就要把断开的“树枝”接到整个索引树上，同时，还需要对文件所属inode结构中的有关内容做一些调整。这些操作都是由ext2_splice_branch（）函数完成。

到此为止，万事具备，则转到标号got_it处，把映射后的数据块连同设备号置入bh_result所指的缓冲区结构中，这就完成了数据块的分配。

10.1.1 什么是模块

模块是内核的一部分（通常是设备驱动程序），但是并没有被编译到内核里面去。它们被分别编译并连接成一组目标文件，这些文件能被插入到正在运行的内核，或者从正在运行的内核中移走，进行这些操作可以使用insmod(插入模块)或rmmod(移走模块)命令，或者，在必要的时候，内核本身能请求内核守护进程(kerned)装入或卸下模块。这里列出在Linux内核源程序中所包括的一些模块：

·      文件系统: minix, xiafs, msdos, umsdos, sysv, isofs, hpfs,

smbfs, ext3,nfs，proc等

·      大多数SCSI 驱动程序: (如： aha1542, in2000)

·      所有的SCSI 高级驱动程序: disk, tape, cdrom, generic.

·      大多数以太网驱动程序: ( 非常多，不便于在这儿列出，请查看

./Documentation/networking/net-modules.txt)

·      大多数 CD-ROM 驱动程序:

aztcd:     Aztech,Orchid,Okano,Wearnes

cm206:     Philips/LMS CM206

gscd:      Goldstar GCDR-420

mcd, mcdx: Mitsumi LU005, FX001

optcd:     Optics Storage Dolphin 8000AT

sjcd:      Sanyo CDR-H94A

sbpcd:     Matsushita/Panasonic CR52x, CR56x, CD200,

Longshine LCS-7260, TEAC CD-55A

sonycd535: Sony CDU-531/535, CDU-510/515

·      以及很多其它模块, 诸如:

lp: 行式打印机

binfmt_elf: elf 装入程序

binfmt_java: java 装入程序

isp16: cd-rom 接口

serial: 串口(tty)

这里要说明的是，Linux内核中的各种文件系统及设备驱动程序，既可以被编译成可安装模块，也可以被静态地编译进内核的映象中，这取决于内核编译之前的系统配置阶段用户的选择。通常，在系统的配置阶段，系统会给出三种选择（Y/M/N），“Y”表示要某种设备或功能，并将相应的代码静态地连接在内核映像中；“M”表示将代码编译成可安装模块，“N”表示不安装这种设备。

10.1.2为什么要使用模块?

按需动态装入模块是非常吸引人的，因为这样可以保证内核达到最小并且使得内核非常灵活，例如，当你可能偶尔使用 VFAT文件系统，你只要安装(mount) VFAT，VFAT文件系统就成为一个可装入模块，kerneld通过自动装入VFAT文件系统建立你的Linux内核，当你卸下(unmount )VFAT部分时，系统检测到你不再需要的FAT系统模块，该模块自动地从内核中被移走。按需动态装入模块还意味着，你会有更多的内存给用户程序。如前所述，内核所使用的内存是永远不会被换出的，因此，如果你有100kb不使用的驱动程序被编译进内核，那就意味着你在浪费RAM。任何事情都是要付出代价的，内核模块的这种优势是以性能和内存的轻微损失为代价的。

一旦一个Linux内核模块被装入，那么它就象任何标准的内核代码一样成为内核的一部分，它和任何内核代码一样具有相同的权限和职责。像所有的内核代码或驱动程序一样，Linux内核模块也能使内核崩溃。

10.1.3 Linux 内核模块的优缺点

利用内核模块的动态装载性具有如下优点：

·将内核映象的尺寸保持在最小，并具有最大的灵活性；
·便于检验新的内核代码，而不需重新编译内核并重新引导。

但是，内核模块的引入也带来了如下问题：

·对系统性能和内存利用有负面影响；
·装入的内核模块和其他内核部分一样，具有相同的访问权限，因此，差的内核模            块会导致系统崩溃；
·为了使内核模块访问所有内核资源，内核必须维护符号表，并在装入和卸载模块时    修改这些符号表；
·有些模块要求利用其他模块的功能，因此，内核要维护模块之间的依赖性。
·内核必须能够在卸载模块时通知模块，并且要释放分配给模块的内存和中断等资             源；
·内核版本和模块版本的不兼容，也可能导致系统崩溃，因此，严格的版本检查是必需的。
尽管内核模块的引入同时也带来不少问题，但是模块机制确实是扩充内核功能一种行之有效的方法，也是在内核级进行编程的有效途径。

10.2.1数据结构
1．模块符号

如前所述，Linux内核是一个整体结构，而模块是插入到内核中的插件。尽管内核不是一个可安装模块，但为了方便起见，Linux把内核也看作一个模块。那么模块与模块之间如何进行交互呢，一种常用的方法就是共享变量和函数。但并不是模块中的每个变量和函数都能被共享，内核只把各个模块中主要的变量和函数放在一个特定的区段，这些变量和函数就统称为符号。到低哪些符号可以被共享？ Linux内核有自己的规定。对于内核模块，在kernel/ksyms.c中定义了从中可以“移出”的符号，例如进程管理子系统可以“移出”的符号定义如下：

/* process memory management */

EXPORT_SYMBOL(do_mmap_pgoff);

EXPORT_SYMBOL(do_munmap);

EXPORT_SYMBOL(do_brk);

EXPORT_SYMBOL(exit_mm);

EXPORT_SYMBOL(exit_files);

EXPORT_SYMBOL(exit_fs);

EXPORT_SYMBOL(exit_sighand);

EXPORT_SYMBOL(complete_and_exit);

EXPORT_SYMBOL(__wake_up);

EXPORT_SYMBOL(__wake_up_sync);

EXPORT_SYMBOL(wake_up_process);

EXPORT_SYMBOL(sleep_on);

EXPORT_SYMBOL(sleep_on_timeout);

EXPORT_SYMBOL(interruptible_sleep_on);

EXPORT_SYMBOL(interruptible_sleep_on_timeout);

EXPORT_SYMBOL(schedule);

EXPORT_SYMBOL(schedule_timeout);

EXPORT_SYMBOL(jiffies);

EXPORT_SYMBOL(xtime);

EXPORT_SYMBOL(do_gettimeofday);

EXPORT_SYMBOL(do_settimeofday);

你可能对这些变量和函数已经很熟悉。其中宏定义EXPORT_SYMBOL（）本身的含义是“移出符号”。为什么说是“移出”呢？因为这些符号本来是内核内部的符号，通过这个宏放在一个公开的地方，使得装入到内核中的其他模块可以引用它们。

实际上，仅仅知道这些符号的名字是不够的，还得知道它们在内核映像中的地址才有意义。因此，内核中定义了如下结构来描述模块的符号：

struct module_symbol

{

unsigned long value; ／*符号在内核映像中的地址*/

const char *name;   /*指向符号名的指针*/

};

从后面对EXPORT_SYMBOL宏的定义可以看出，连接程序（ld）在连接内核映像时将这个结构存放在一个叫做“__ksymtab”的区段中，而这个区段中所有的符号就组成了模块对外“移出”的符号表，这些符号可供内核及已安装的模块来引用。而其他“对内”的符号则由连接程序自行生成，并仅供内部使用。

与EXPORT_SYMBOL相关的定义在include/linux/module.h中：

#define __MODULE_STRING_1(x)    #x

#define __MODULE_STRING(x)      __MODULE_STRING_1(x)

#define __EXPORT_SYMBOL(sym, str)                       /

const char __kstrtab_##sym[]                            /

__attribute__((section(".kstrtab"))) = str;             /

const struct module_symbol __ksymtab_##sym              /

__attribute__((section("__ksymtab"))) =                 /

{ (unsigned long)&sym, __kstrtab_##sym }

#if defined(MODVERSIONS) || !defined(CONFIG_MODVERSIONS)

#define EXPORT_SYMBOL(var) __EXPORT_SYMBOL(var, __MODULE_STRING(var))

下面我们以EXPORT_SYMBOL(schedule)为例，来看一下这个宏的结果是什么。

首先EXPORT_SYMBOL(schedule)的定义成了__EXPORT_SYMBOL(schedule, “schedule”)。而__EXPORT_SYMBOL（）定义了两个语句，第一个语句定义了一个名为__kstrtab_ schedule的字符串，将字符串的内容初始化为“schedule”，并将其置于内核映像中的.kstrtab区段，注意这是一个专门存放符号名字符串的区段。第二个语句则定义了一个名为__kstrtab_ schedule的module_symbol结构，将其初始化为｛＆schedule，__kstrtab_ schedule｝结构，并将其置于内核映像中的__ksymtab区段。这样，module_symbol结构中的域value的值就为schedule在内核映像中的地址，而指针name则指向字符串“schedule”。

2．模块引用(module reference)

模块引用是一个不太好理解的概念。 有些装入内核的模块必须依赖其它模块， 例如，因为VFAT文件系统是FAT文件系统或多或少的扩充集，那么，VFAT文件系统依赖（depend）于FAT文件系统，或者说，FAT模块被VFAT模块引用，或换句话说，VFAT为“父”模块，FAT为“子”模块。其结构如下：

struct module_ref

{

struct module *dep;     /* “父”模块指针*/

struct module *ref;     /* “子”模块指针*/

struct module_ref *next_ref; ／*指向下一个子模块的指针*/

};

在这里“dep”指的是依赖，也就是引用，而“ref”指的是被引用。因为模块引用的关系可能延续下去，例如A引用B，B有引用C，因此，模块的引用形成一个链表。

3． 模块

模块的结构为module ，其定义如下：

struct module_persist; /* 待决定 */

struct module

{

unsigned long size_of_struct;   /* 模块结构的大小，即sizeof(module) */

struct module *next; ／* 指向下一个模块 */

const char *name;   ／*模块名，最长为64个字符*/
        unsigned long size; ／*以页为单位的模块大小*/

union

{

atomic_t usecount; ／*使用计数，对其增减是原子操作*/

long pad;

} uc;                      /* Needs to keep its size - so says rth */

unsigned long flags;            /* 模块的标志 */

unsigned nsyms;        /* 模块中符号的个数 */

unsigned ndeps;       /* 模块依赖的个数 */

struct module_symbol *syms; /* 指向模块的符号表,表的大小为nsyms */

struct module_ref deps; ／*指向模块引用的数组，大小为ndeps */

struct module_ref *refs;

int (*init)(void);      /* 指向模块的init_module()函数 */

void (*cleanup)(void); /* 指向模块的cleanup_module()函数 */

const struct exception_table_entry *ex_table_start;

const struct exception_table_entry *ex_table_end;

/* 以下域是在以上基本域的基础上的一种扩展，因此是可选的。可以调用

mod_member_present()函数来检查以下域的存在与否。 */

const struct module_persist *persist_start; ／*尚未定义*/

const struct module_persist *persist_end;

int (*can_unload)(void);

int runsize                      ／*尚未使用*/

const char *kallsyms_start;     /*用于内核调试的所有符号 */

const char *kallsyms_end;

const char *archdata_start;     /* 与体系结构相关的特定数据*/

const char *archdata_end;

const char *kernel_data;        /*保留 */

};

其中，moudle中的状态，即flags的取值定义如下：

/* Bits of module.flags. */

#define MOD_UNINITIALIZED       0 ／*模块还未初始化*/

#define MOD_RUNNING             1 ／*模块正在运行*/

#define MOD_DELETED             2 ／*卸载模块的过程已经启动*/

#define MOD_AUTOCLEAN           4 ／*安装模块时带有此标记，表示允许自动

卸载模块*/

#define MOD_VISITED             8 ／*模块被访问过*/

#define MOD_USED_ONCE           16 ／*模块已经使用过一次*/

#define MOD_JUST_FREED          32 ／*模块刚刚被释放*/

#define MOD_INITIALIZING        64 ／*正在进行模块的初始化*/－／

如前所述，虽然内核不是可安装模块，但它也有符号表，实际上这些符号表受到其他模块的频繁引用，将内核看作可安装模块大大简化了模块设计。因此，内核也有一个module结构，叫做kernel_module，与kernel_module相关的定义在kernel／module_c中：

#if defined(CONFIG_MODULES) || defined(CONFIG_KALLSYMS)

extern struct module_symbol __start___ksymtab[];

extern struct module_symbol __stop___ksymtab[];

extern const struct exception_table_entry __start___ex_table[];

extern const struct exception_table_entry __stop___ex_table[];

extern const char __start___kallsyms[] __attribute__ ((weak));

extern const char __stop___kallsyms[] __attribute__ ((weak));

struct module kernel_module =

{

size_of_struct:         sizeof(struct module),

name:                   "",

uc:                     {ATOMIC_INIT(1)},

flags:                  MOD_RUNNING,

syms:                   __start___ksymtab,

ex_table_start:         __start___ex_table,

ex_table_end:           __stop___ex_table,

kallsyms_start:         __start___kallsyms,

kallsyms_end:           __stop___kallsyms,

};

首先要说明的是，内核对可安装模块的的支持是可选的。如果在编译内核代码之前的系统配置阶段选择了可安装模块，就定义了编译提示CONFIG_MODULES，使支持可安装模块的代码受到编译。同理，对用于内核调试的符号的支持也是可选的。

凡是在以上初始值未出现的域，其值均为0或NULL。显然，内核没有init_module()和cleanup_module()函数，因为内核不是一个真正的可安装模块。同时，内核没有deps数组，开始时也没有refs链。可是，这个结构的指针syms指向__start___ksymtab，这就是内核符号表的起始地址。符号表的大小nsyms为0，但是在系统能初始化时会在init_module()函数中将其设置成正确的值。

在模块映像中也可以包含对异常的处理。发生于一些特殊地址上的异常，可以通过一种描述结构exception_table_entry规定对异常的反映和处理，这些结构在可执行映像连接时都被集中在一个数组中，内核的exception_table_entry结构数组就为__start___ex_table［］。当异常发生时，内核的异常响应处理程序就会先搜索这个数组，看看是否对所发生的异常规定了特殊的处理，相关内容请看第四章。

另外，从kernel_module开始，所有已安装模块的module结构都链在一起成为一条链，内核中的全局变量module_list就指向这条链：

struct module *module_list = &kernel_module；