README.txt 8.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258
  1. README
  2. ======
  3. o Overview
  4. o gencromfs
  5. o Architecture
  6. o Configuration
  7. Overview
  8. ========
  9. This directory contains the the CROMFS file system. This is an in-memory
  10. (meaning no block driver), read-only (meaning that can lie in FLASH) file
  11. system. It uses LZF decompression on data only (meta data is not
  12. compressed).
  13. It accesses the in-memory file system via directory memory reads and, hence,
  14. can only reside in random access NOR-like FLASH. It is intended for use
  15. with on-chip FLASH available on most MCUs (the design could probably be
  16. extended to access non-random-access FLASH as well, but those extensions
  17. are not yet in place).
  18. I do not have a good way to measure how much compression we get using LZF.
  19. I have seen 37% compression reported in other applications, so I have to
  20. accept that for now. That means, for example, that you could have a file
  21. system with 512Kb of data in only 322Kb of FLASH, giving you 190Kb to do
  22. other things with.
  23. LZF compression is not known for its high compression ratios, but rather
  24. for fast decompression. According to the author of the LZF decompression
  25. routine, it is nearly as fast as a memcpy!
  26. There is also a new tool at /tools/gencromfs.c that will generate binary
  27. images for the NuttX CROMFS file system and and an example CROMFS file
  28. system image at apps/examples/cromfs. That example includes a test file
  29. system that looks like:
  30. $ ls -Rl ../apps/examples/cromfs/cromfs
  31. ../apps/examples/cromfs/cromfs:
  32. total 2
  33. -rwxr--r--+ 1 spuda spuda 171 Mar 20 08:02 BaaBaaBlackSheep.txt
  34. drwxrwxr-x+ 1 spuda spuda 0 Mar 20 08:11 emptydir
  35. -rwxr--r--+ 1 spuda spuda 118 Mar 20 08:05 JackSprat.txt
  36. drwxrwxr-x+ 1 spuda spuda 0 Mar 20 08:06 testdir1
  37. drwxrwxr-x+ 1 spuda spuda 0 Mar 20 08:10 testdir2
  38. drwxrwxr-x+ 1 spuda spuda 0 Mar 20 08:05 testdir3
  39. ../apps/examples/cromfs/cromfs/emptydir:
  40. total 0
  41. ../apps/examples/cromfs/cromfs/testdir1:
  42. total 2
  43. -rwxr--r--+ 1 spuda spuda 249 Mar 20 08:03 DingDongDell.txt
  44. -rwxr--r--+ 1 spuda spuda 247 Mar 20 08:06 SeeSawMargorieDaw.txt
  45. ../apps/examples/cromfs/cromfs/testdir2:
  46. total 5
  47. -rwxr--r--+ 1 spuda spuda 118 Mar 20 08:04 HickoryDickoryDock.txt
  48. -rwxr--r--+ 1 spuda spuda 2082 Mar 20 08:10 TheThreeLittlePigs.txt
  49. ../apps/examples/cromfs/cromfs/testdir3:
  50. total 1
  51. -rwxr--r--+ 1 spuda spuda 138 Mar 20 08:05 JackBeNimble.txt
  52. When built into NuttX and deployed on a target, it looks like:
  53. NuttShell (NSH) NuttX-7.24
  54. nsh> mount -t cromfs /mnt/cromfs
  55. nsh> ls -Rl /mnt/cromfs
  56. /mnt/cromfs:
  57. dr-xr-xr-x 0 .
  58. -rwxr--r-- 171 BaaBaaBlackSheep.txt
  59. dr-xr-xr-x 0 emptydir/
  60. -rwxr--r-- 118 JackSprat.txt
  61. dr-xr-xr-x 0 testdir1/
  62. dr-xr-xr-x 0 testdir2/
  63. dr-xr-xr-x 0 testdir3/
  64. /mnt/cromfs/emptydir:
  65. drwxrwxr-x 0 .
  66. dr-xr-xr-x 0 ..
  67. /mnt/cromfs/testdir1:
  68. drwxrwxr-x 0 .
  69. dr-xr-xr-x 0 ..
  70. -rwxr--r-- 249 DingDongDell.txt
  71. -rwxr--r-- 247 SeeSawMargorieDaw.txt
  72. /mnt/cromfs/testdir2:
  73. drwxrwxr-x 0 .
  74. dr-xr-xr-x 0 ..
  75. -rwxr--r-- 118 HickoryDickoryDock.txt
  76. -rwxr--r-- 2082 TheThreeLittlePigs.txt
  77. /mnt/cromfs/testdir3:
  78. drwxrwxr-x 0 .
  79. dr-xr-xr-x 0 ..
  80. -rwxr--r-- 138 JackBeNimble.txt
  81. nsh>
  82. Everything I have tried works: examining directories, catting files, etc.
  83. The "." and ".." hard links also work:
  84. nsh> cd /mnt/cromfs
  85. nsh> cat emptydir/../testdir1/DingDongDell.txt
  86. Ding, dong, bell,
  87. Pussy's in the well.
  88. Who put her in?
  89. Little Johnny Green.
  90. Who pulled her out?
  91. Little Tommy Stout.
  92. What a naughty boy was that,
  93. To try to drown poor pussy cat,
  94. Who never did him any harm,
  95. And killed the mice in his father's barn.
  96. nsh>
  97. gencromfs
  98. =========
  99. The genromfs program can be found in tools/. It is a single C file called
  100. gencromfs.c. It can be built in this way:
  101. cd tools
  102. make -f Makefile.host gencromfs
  103. The genromfs tool used to generate CROMFS file system images. Usage is
  104. simple:
  105. gencromfs <dir-path> <out-file>
  106. Where:
  107. <dir-path> is the path to the directory will be at the root of the
  108. new CROMFS file system image.
  109. <out-file> the name of the generated, output C file. This file must
  110. be compiled in order to generate the binary CROMFS file system
  111. image.
  112. All of these steps are automated in the apps/examples/cromfs/Makefile.
  113. Refer to that Makefile as an reference.
  114. Architecture
  115. ============
  116. The CROMFS file system is represented by an in-memory data structure. This
  117. structure is a "tree." At the root of the tree is a "volume node" that
  118. describes the overall operating system. Other entities within the file
  119. system are presented by other types of nodes: hard links, directories, and
  120. files. These nodes are all described in fs/cromfs/cromfs.h.
  121. In addition to general volume information, the volume node provides an
  122. offset to the the "root directory". The root directory, like all other
  123. CROMFS directories is simply a singly linked list of other nodes: hard link
  124. nodes, directory nodes, and files. This list is managed by "peer offsets":
  125. Each node in the directory contains an offset to its peer in the same
  126. directory. This directory list is terminated with a zero offset.
  127. The volume header lies at offset zero. Hence, any offset to a node or data
  128. block can be converted to an absolute address in the in-memory CROMFS image
  129. by simply adding that offset to the well-known address of the volume header.
  130. Each hard link, directory, and file node in the directory list includes
  131. such a "peer offset" to the next node in the list. Each node is followed
  132. by the NUL-terminated name of the node. Each node also holds an additional
  133. offset. Directory nodes contain a "child offset". That is, the offset to
  134. the first entry in another singly linked list of nodes comprising the sub-
  135. directory.
  136. Hard link nodes hold the "link offset" to the node which is the target of
  137. the link. The link offset may be an offset to another hard link node, to a
  138. directory, or to a file node. The directory link offset would refer the
  139. first node in singly linked directory list that represents the directory.
  140. File nodes provide file data. The file name string is followed by a
  141. variable length list of compressed data blocks. In this case each
  142. compressed data block begins with an LZF header as described in
  143. include/lzf.h.
  144. So, given this description, we could illustrate the sample CROMFS file
  145. system above with these nodes (where V=volume node, H=Hard link node,
  146. D=directory node, F=file node, D=Data block):
  147. V
  148. `- +- H: .
  149. |
  150. +- F: BaaBaaBlackSheep.txt
  151. | `- D,D,D,...D
  152. +- D: emptydir
  153. | |- H: .
  154. | `- H: ..
  155. +- F: JackSprat.txt
  156. | `- D,D,D,...D
  157. +- D: testdir1
  158. | |- H: .
  159. | |- H: ..
  160. | |- F: DingDongDell.txt
  161. | | `- D,D,D,...D
  162. | `- F: SeeSawMargorieDaw.txt
  163. | `- D,D,D,...D
  164. +- D: testdir2
  165. | |- H: .
  166. | |- H: ..
  167. | |- F: HickoryDickoryDock.txt
  168. | | `- D,D,D,...D
  169. | `- F: TheThreeLittlePigs.txt
  170. | `- D,D,D,...D
  171. +- D: testdir3
  172. |- H: .
  173. |- H: ..
  174. `- F: JackBeNimble.txt
  175. `- D,D,D,...D
  176. Where, for example:
  177. H: ..
  178. Represents a hard-link node with name ".."
  179. |
  180. +- D: testdir1
  181. | |- H: .
  182. Represents a directory node named "testdir1". The first node of the
  183. directory list is a hard link with name "."
  184. |
  185. +- F: JackSprat.txt
  186. | `- D,D,D,...D
  187. Represents f file node named "JackSprat.txt" and is followed by some
  188. sequence of compressed data blocks, D.
  189. Configuration
  190. =============
  191. To build the CROMFS file system, you would add the following to your
  192. configuration:
  193. 1. Enable LZF (The other LZF settings apply only to compression
  194. and, hence, have no impact on CROMFS which only decompresses):
  195. CONFIG_LIBC_LZF=y
  196. NOTE: This should be selected automatically when CONFIG_FS_CROMFS
  197. is enabled.
  198. 2. Enable the CROMFS file system:
  199. CONFIG_FS_CROMFS=y
  200. 3. Enable the apps/examples/cromfs example:
  201. CONFIG_EXAMPLES_CROMFS=y
  202. Or the apps/examples/elf example if you like:
  203. CONFIG_ELF=y
  204. # CONFIG_BINFMT_DISABLE is not set
  205. CONFIG_EXAMPLES_ELF=y
  206. CONFIG_EXAMPLES_ELF_CROMFS=y
  207. Or implement your own custom CROMFS file system that example as a
  208. guideline.