Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

docs: filesystems: convert romfs.txt to ReST

- Add a SPDX header;
- Add a document title;
- Some whitespace fixes and new line breaks;
- Mark literal blocks as such;
- Add table markups;
- Add it to filesystems/index.rst.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/d2cc83e7cd6de63c793ccd3f2588ea40f7f1e764.1581955849.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

authored by

Mauro Carvalho Chehab and committed by
Jonathan Corbet
6db0a480 56e6d5c0

+26 -17
+1
Documentation/filesystems/index.rst
··· 85 85 qnx6 86 86 ramfs-rootfs-initramfs 87 87 relay 88 + romfs 88 89 virtiofs 89 90 vfat
+25 -17
Documentation/filesystems/romfs.txt Documentation/filesystems/romfs.rst
··· 1 - ROMFS - ROM FILE SYSTEM 1 + .. SPDX-License-Identifier: GPL-2.0 2 + 3 + ======================= 4 + ROMFS - ROM File System 5 + ======================= 2 6 3 7 This is a quite dumb, read only filesystem, mainly for initial RAM 4 8 disks of installation disks. It has grown up by the need of having ··· 55 51 bytes. This is quite rare however, since most file names are longer 56 52 than 3 bytes, and shorter than 15 bytes. 57 53 58 - The layout of the filesystem is the following: 54 + The layout of the filesystem is the following:: 59 55 60 - offset content 56 + offset content 61 57 62 58 +---+---+---+---+ 63 59 0 | - | r | o | m | \ ··· 88 84 reliable, it does not require any tables, and it is very simple. 89 85 90 86 The following bytes are now part of the file system; each file header 91 - must begin on a 16 byte boundary. 87 + must begin on a 16 byte boundary:: 92 88 93 - offset content 89 + offset content 94 90 95 91 +---+---+---+---+ 96 92 0 | next filehdr|X| The offset of the next file header ··· 118 114 intended use. The mapping of the 8 possible values to file types is 119 115 the following: 120 116 117 + == =============== ============================================ 121 118 mapping spec.info means 119 + == =============== ============================================ 122 120 0 hard link link destination [file header] 123 121 1 directory first file's header 124 122 2 regular file unused, must be zero [MBZ] ··· 129 123 5 char device - " - 130 124 6 socket unused, MBZ 131 125 7 fifo unused, MBZ 126 + == =============== ============================================ 132 127 133 128 Note that hard links are specifically marked in this filesystem, but 134 129 they will behave as you can expect (i.e. share the inode number). ··· 165 158 Pending issues: 166 159 167 160 - Permissions and owner information are pretty essential features of a 168 - Un*x like system, but romfs does not provide the full possibilities. 169 - I have never found this limiting, but others might. 161 + Un*x like system, but romfs does not provide the full possibilities. 162 + I have never found this limiting, but others might. 170 163 171 164 - The file system is read only, so it can be very small, but in case 172 - one would want to write _anything_ to a file system, he still needs 173 - a writable file system, thus negating the size advantages. Possible 174 - solutions: implement write access as a compile-time option, or a new, 175 - similarly small writable filesystem for RAM disks. 165 + one would want to write _anything_ to a file system, he still needs 166 + a writable file system, thus negating the size advantages. Possible 167 + solutions: implement write access as a compile-time option, or a new, 168 + similarly small writable filesystem for RAM disks. 176 169 177 170 - Since the files are only required to have alignment on a 16 byte 178 - boundary, it is currently possibly suboptimal to read or execute files 179 - from the filesystem. It might be resolved by reordering file data to 180 - have most of it (i.e. except the start and the end) laying at "natural" 181 - boundaries, thus it would be possible to directly map a big portion of 182 - the file contents to the mm subsystem. 171 + boundary, it is currently possibly suboptimal to read or execute files 172 + from the filesystem. It might be resolved by reordering file data to 173 + have most of it (i.e. except the start and the end) laying at "natural" 174 + boundaries, thus it would be possible to directly map a big portion of 175 + the file contents to the mm subsystem. 183 176 184 177 - Compression might be an useful feature, but memory is quite a 185 - limiting factor in my eyes. 178 + limiting factor in my eyes. 186 179 187 180 - Where it is used? 188 181 ··· 190 183 191 184 192 185 Have fun, 186 + 193 187 Janos Farkas <chexum@shadow.banki.hu>