mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-12-28 16:56:26 +00:00
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>
This commit is contained in:
parent
56e6d5c0eb
commit
6db0a480aa
@ -85,5 +85,6 @@ Documentation for filesystem implementations.
|
||||
qnx6
|
||||
ramfs-rootfs-initramfs
|
||||
relay
|
||||
romfs
|
||||
virtiofs
|
||||
vfat
|
||||
|
@ -1,4 +1,8 @@
|
||||
ROMFS - ROM FILE SYSTEM
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=======================
|
||||
ROMFS - ROM File System
|
||||
=======================
|
||||
|
||||
This is a quite dumb, read only filesystem, mainly for initial RAM
|
||||
disks of installation disks. It has grown up by the need of having
|
||||
@ -51,9 +55,9 @@ the 16 byte padding for the name and the contents, also 16+14+15 = 45
|
||||
bytes. This is quite rare however, since most file names are longer
|
||||
than 3 bytes, and shorter than 15 bytes.
|
||||
|
||||
The layout of the filesystem is the following:
|
||||
The layout of the filesystem is the following::
|
||||
|
||||
offset content
|
||||
offset content
|
||||
|
||||
+---+---+---+---+
|
||||
0 | - | r | o | m | \
|
||||
@ -84,9 +88,9 @@ the source. This algorithm was chosen because although it's not quite
|
||||
reliable, it does not require any tables, and it is very simple.
|
||||
|
||||
The following bytes are now part of the file system; each file header
|
||||
must begin on a 16 byte boundary.
|
||||
must begin on a 16 byte boundary::
|
||||
|
||||
offset content
|
||||
offset content
|
||||
|
||||
+---+---+---+---+
|
||||
0 | next filehdr|X| The offset of the next file header
|
||||
@ -114,7 +118,9 @@ file is user and group 0, this should never be a problem for the
|
||||
intended use. 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]
|
||||
@ -123,6 +129,7 @@ the following:
|
||||
5 char device - " -
|
||||
6 socket unused, MBZ
|
||||
7 fifo unused, MBZ
|
||||
== =============== ============================================
|
||||
|
||||
Note that hard links are specifically marked in this filesystem, but
|
||||
they will behave as you can expect (i.e. share the inode number).
|
||||
@ -158,24 +165,24 @@ to romfs-subscribe@shadow.banki.hu, the content is irrelevant.
|
||||
Pending issues:
|
||||
|
||||
- Permissions and owner information are pretty essential features of a
|
||||
Un*x like system, but romfs does not provide the full possibilities.
|
||||
I have never found this limiting, but others might.
|
||||
Un*x like system, but romfs does not provide the full possibilities.
|
||||
I have never found this limiting, but others might.
|
||||
|
||||
- The file system is read only, so it can be very small, but in case
|
||||
one would want to write _anything_ to a file system, he still needs
|
||||
a writable file system, thus negating the size advantages. Possible
|
||||
solutions: implement write access as a compile-time option, or a new,
|
||||
similarly small writable filesystem for RAM disks.
|
||||
one would want to write _anything_ to a file system, he still needs
|
||||
a writable file system, thus negating the size advantages. Possible
|
||||
solutions: implement write access as a compile-time option, or a new,
|
||||
similarly small writable filesystem for RAM disks.
|
||||
|
||||
- Since the files are only required to have alignment on a 16 byte
|
||||
boundary, it is currently possibly suboptimal to read or execute files
|
||||
from the filesystem. It might be resolved by reordering file data to
|
||||
have most of it (i.e. except the start and the end) laying at "natural"
|
||||
boundaries, thus it would be possible to directly map a big portion of
|
||||
the file contents to the mm subsystem.
|
||||
boundary, it is currently possibly suboptimal to read or execute files
|
||||
from the filesystem. It might be resolved by reordering file data to
|
||||
have most of it (i.e. except the start and the end) laying at "natural"
|
||||
boundaries, thus it would be possible to directly map a big portion of
|
||||
the file contents to the mm subsystem.
|
||||
|
||||
- Compression might be an useful feature, but memory is quite a
|
||||
limiting factor in my eyes.
|
||||
limiting factor in my eyes.
|
||||
|
||||
- Where it is used?
|
||||
|
||||
@ -183,4 +190,5 @@ limiting factor in my eyes.
|
||||
|
||||
|
||||
Have fun,
|
||||
|
||||
Janos Farkas <chexum@shadow.banki.hu>
|
Loading…
Reference in New Issue
Block a user