From f1fa0e6028d395c5f0d1a0929a795b8dc0d43295 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 17 Feb 2020 17:11:56 +0100 Subject: docs: filesystems: convert cramfs.txt to ReST - Add a SPDX header; - Adjust 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 Acked-by: Nicolas Pitre Link: https://lore.kernel.org/r/e87b267e71f99974b7bb3fc0a4a08454ff58165e.1581955849.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/filesystems/cramfs.txt | 118 ----------------------------------- 1 file changed, 118 deletions(-) delete mode 100644 Documentation/filesystems/cramfs.txt (limited to 'Documentation/filesystems/cramfs.txt') diff --git a/Documentation/filesystems/cramfs.txt b/Documentation/filesystems/cramfs.txt deleted file mode 100644 index 8e19a53d648b..000000000000 --- a/Documentation/filesystems/cramfs.txt +++ /dev/null @@ -1,118 +0,0 @@ - - Cramfs - cram a filesystem onto a small ROM - -cramfs is designed to be simple and small, and to compress things well. - -It uses the zlib routines to compress a file one page at a time, and -allows random page access. The meta-data is not compressed, but is -expressed in a very terse representation to make it use much less -diskspace than traditional filesystems. - -You can't write to a cramfs filesystem (making it compressible and -compact also makes it _very_ hard to update on-the-fly), so you have to -create the disk image with the "mkcramfs" utility. - - -Usage Notes ------------ - -File sizes are limited to less than 16MB. - -Maximum filesystem size is a little over 256MB. (The last file on the -filesystem is allowed to extend past 256MB.) - -Only the low 8 bits of gid are stored. The current version of -mkcramfs simply truncates to 8 bits, which is a potential security -issue. - -Hard links are supported, but hard linked files -will still have a link count of 1 in the cramfs image. - -Cramfs directories have no `.' or `..' entries. Directories (like -every other file on cramfs) always have a link count of 1. (There's -no need to use -noleaf in `find', btw.) - -No timestamps are stored in a cramfs, so these default to the epoch -(1970 GMT). Recently-accessed files may have updated timestamps, but -the update lasts only as long as the inode is cached in memory, after -which the timestamp reverts to 1970, i.e. moves backwards in time. - -Currently, cramfs must be written and read with architectures of the -same endianness, and can be read only by kernels with PAGE_SIZE -== 4096. At least the latter of these is a bug, but it hasn't been -decided what the best fix is. For the moment if you have larger pages -you can just change the #define in mkcramfs.c, so long as you don't -mind the filesystem becoming unreadable to future kernels. - - -Memory Mapped cramfs image --------------------------- - -The CRAMFS_MTD Kconfig option adds support for loading data directly from -a physical linear memory range (usually non volatile memory like Flash) -instead of going through the block device layer. This saves some memory -since no intermediate buffering is necessary to hold the data before -decompressing. - -And when data blocks are kept uncompressed and properly aligned, they will -automatically be mapped directly into user space whenever possible providing -eXecute-In-Place (XIP) from ROM of read-only segments. Data segments mapped -read-write (hence they have to be copied to RAM) may still be compressed in -the cramfs image in the same file along with non compressed read-only -segments. Both MMU and no-MMU systems are supported. This is particularly -handy for tiny embedded systems with very tight memory constraints. - -The location of the cramfs image in memory is system dependent. You must -know the proper physical address where the cramfs image is located and -configure an MTD device for it. Also, that MTD device must be supported -by a map driver that implements the "point" method. Examples of such -MTD drivers are cfi_cmdset_0001 (Intel/Sharp CFI flash) or physmap -(Flash device in physical memory map). MTD partitions based on such devices -are fine too. Then that device should be specified with the "mtd:" prefix -as the mount device argument. For example, to mount the MTD device named -"fs_partition" on the /mnt directory: - -$ mount -t cramfs mtd:fs_partition /mnt - -To boot a kernel with this as root filesystem, suffice to specify -something like "root=mtd:fs_partition" on the kernel command line. - - -Tools ------ - -A version of mkcramfs that can take advantage of the latest capabilities -described above can be found here: - -https://github.com/npitre/cramfs-tools - - -For /usr/share/magic --------------------- - -0 ulelong 0x28cd3d45 Linux cramfs offset 0 ->4 ulelong x size %d ->8 ulelong x flags 0x%x ->12 ulelong x future 0x%x ->16 string >\0 signature "%.16s" ->32 ulelong x fsid.crc 0x%x ->36 ulelong x fsid.edition %d ->40 ulelong x fsid.blocks %d ->44 ulelong x fsid.files %d ->48 string >\0 name "%.16s" -512 ulelong 0x28cd3d45 Linux cramfs offset 512 ->516 ulelong x size %d ->520 ulelong x flags 0x%x ->524 ulelong x future 0x%x ->528 string >\0 signature "%.16s" ->544 ulelong x fsid.crc 0x%x ->548 ulelong x fsid.edition %d ->552 ulelong x fsid.blocks %d ->556 ulelong x fsid.files %d ->560 string >\0 name "%.16s" - - -Hacker Notes ------------- - -See fs/cramfs/README for filesystem layout and implementation notes. -- cgit