--------------------------------------------------------------------------------
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