romfs 文件系统学习

--------------------------------------------------------------------------------
1. romfs 文件组织
--------------------------------------------------------------------------------
    +---+---+---+---+
  0 | - | r | o | m |  \
    +---+---+---+---+    The ASCII representation of those bytes
  4 | 1 | f | s | - |  /    (i.e. "-rom1fs-")
    +---+---+---+---+
  8 |   full size   |    The number of accessible bytes in this fs.
    +---+---+---+---+
 12 |    checksum   |    The checksum of the FIRST 512 BYTES.
    +---+---+---+---+
 16 | volume name   |    The zero terminated name of the volume,
    :               :    padded to 16 byte boundary.
    +---+---+---+---+
 xx |     file      |
    :    headers    :


offset        content

    +---+---+---+---+
  0 | next filehdr|X|    The offset of the next file header
    +---+---+---+---+      (zero if no more files)
  4 |   spec.info   |    Info for directories/hard links/devices
    +---+---+---+---+
  8 |     size      |    The size of this file in bytes
    +---+---+---+---+
 12 |   checksum    |    Covering the meta data, including the file
    +---+---+---+---+      name, and padding
 16 | file name     |    The zero terminated name of the file,
    :               :    padded to 16 byte boundary
    +---+---+---+---+
 xx | file data     |
    :        :

Since the file headers begin always at a 16 byte boundary, the lowest
4 bits would be always zero in the next filehdr pointer.  These four
bits are used for the mode information.  Bits 0..2 specify the type of
the file; while bit 3 shows if the file is executable or not.  
The mapping of the 8 possible values to file types is
the following:

      mapping        spec.info means
 0    hard link    link destination [file header]
 1    directory    first file's header
 2    regular file    unused, must be zero [MBZ]
 3    symbolic link    unused, MBZ (file data is the link content)
 4    block device    16/16 bits major/minor number
 5    char device            - " -
 6    socket        unused, MBZ
 7    fifo        unused, MBZ

别看代码小，它还能支持7种文件格式。

********************************************************************************
romfs 文件的创建 genromfs.c
********************************************************************************
------------------------------
a. 将文件节点导出到设备。
------------------------------
文件的生成是利用 dumpall(root,lastoff,f) 函数来完成。

说实话，文件流程写得并不是很清晰， 细节还得靠揣摩。
好的文件流程，应该尽量是线性的，一看就懂得。

root 是根文件节点， 这些节点组成了链表。 都dump 出来。
lastoff 是用来对齐用的， 与1024 边界对齐，不足者以0填充。
f. 是写入文件指针。

dumpdata 的功能：
dumpdata 是基础的向设备写入数据的函数，主要应用是将bigbuf（4096bytes)数据导出
但并不一定能激发写入操作，而有一个缓冲过程。
前512byte 将会落入 fixbuf 中，填满后，计算其checksum, 写到文件，供文件系统头使用
这是写得混乱的一个地方， 应该把函数拆分。
以后数据，继续写。
以后文件的校验和，就只使用文件头部来校验了。

怎样书写一个文件
这是由dumpnode 来完成的，可以看出，它支持8种文件格式。写的很清楚。
它调用dumpri->dumpdata 来完成数据导出
它有一个变量 romfh, 依据不同的文件类型，填充romfh 域。以普通文件为例：
先dump 一个romfh,
再打开文件，依次写入文件数据。
注意打开文件写数据，是在dump 时完成的。

dump 所有节点， 就是先dupm 系统头，然后再dump 整个文件节点链。

可见，所有过程，需在filenode 节点链建好之后操作。

------------------------------
b. 建立文件节点的过程。
------------------------------
这是读取目录文件，存储信息的过程。它是有processdir 函数来完成的。
这个函数写得也不算太好，例如加上一层level判断就显得功能不单一。
它把初始化过程与执行过程混在了一起。
对于读到的每一个文件，获取文件信息，填充到filenode 中。
它的功能完善之处是，它可以支持8种文件。

问题：
filenode 是何时连接起来的。
答：通过append 函数放到dir->dirlist filenode 链表里
romfh 中下一个文件地址是怎样得到的。
已经建立了文件链表， 由node->next->offset 就可以得到。



romfs
1. 挂接到操作系统中，需要注册文件系统。
2. 需要完成对应的文件系统操作。

对romfs 进行了改写。

编译内核环境: 2.6.32， 其它内核可能需要相应调整
扩展：从32位到64位
提高文件读取效率。
优化方式: 文件节点读入内存,采用数组管理，实现对分搜索，hash 搜索
性能不是很完美，仅供参考.

源代码: csdn 地址如下

http://download.csdn.net/detail/hejinjing_tom_com/6518843