| Alexey Dobriyan | 2a22783 | 2009-01-22 10:56:54 +0300 | [diff] [blame] | 1 | config CRAMFS |
| Nicolas Pitre | 8d59598 | 2017-10-12 02:16:13 -0400 | [diff] [blame] | 2 | tristate "Compressed ROM file system support (cramfs)" |
| Alexey Dobriyan | 2a22783 | 2009-01-22 10:56:54 +0300 | [diff] [blame] | 3 | select ZLIB_INFLATE |
| 4 | help |
| 5 | Saying Y here includes support for CramFs (Compressed ROM File |
| 6 | System). CramFs is designed to be a simple, small, and compressed |
| 7 | file system for ROM based embedded systems. CramFs is read-only, |
| 8 | limited to 256MB file systems (with 16MB files), and doesn't support |
| 9 | 16/32 bits uid/gid, hard links and timestamps. |
| 10 | |
| 11 | See <file:Documentation/filesystems/cramfs.txt> and |
| 12 | <file:fs/cramfs/README> for further information. |
| 13 | |
| 14 | To compile this as a module, choose M here: the module will be called |
| 15 | cramfs. Note that the root file system (the one containing the |
| 16 | directory /) cannot be compiled as a module. |
| 17 | |
| Nicolas Pitre | 8d59598 | 2017-10-12 02:16:13 -0400 | [diff] [blame] | 18 | This filesystem is limited in capabilities and performance on |
| 19 | purpose to remain small and low on RAM usage. It is most suitable |
| 20 | for small embedded systems. If you have ample RAM to spare, you may |
| 21 | consider a more capable compressed filesystem such as SquashFS |
| 22 | which is much better in terms of performance and features. |
| Michael Opdenacker | 54886a7 | 2013-11-12 15:08:35 -0800 | [diff] [blame] | 23 | |
| Alexey Dobriyan | 2a22783 | 2009-01-22 10:56:54 +0300 | [diff] [blame] | 24 | If unsure, say N. |
| Nicolas Pitre | 99c18ce | 2017-10-13 16:09:23 -0400 | [diff] [blame] | 25 | |
| 26 | config CRAMFS_BLOCKDEV |
| 27 | bool "Support CramFs image over a regular block device" if EXPERT |
| 28 | depends on CRAMFS && BLOCK |
| 29 | default y |
| 30 | help |
| 31 | This option allows the CramFs driver to load data from a regular |
| 32 | block device such a disk partition or a ramdisk. |
| 33 | |
| 34 | config CRAMFS_MTD |
| 35 | bool "Support CramFs image directly mapped in physical memory" |
| Nicolas Pitre | a8c6db0 | 2018-02-07 22:08:08 -0500 | [diff] [blame] | 36 | depends on CRAMFS && CRAMFS <= MTD |
| Nicolas Pitre | 99c18ce | 2017-10-13 16:09:23 -0400 | [diff] [blame] | 37 | default y if !CRAMFS_BLOCKDEV |
| 38 | help |
| 39 | This option allows the CramFs driver to load data directly from |
| 40 | a linear adressed memory range (usually non volatile memory |
| 41 | like flash) instead of going through the block device layer. |
| 42 | This saves some memory since no intermediate buffering is |
| 43 | necessary. |
| 44 | |
| 45 | The location of the CramFs image is determined by a |
| 46 | MTD device capable of direct memory mapping e.g. from |
| 47 | the 'physmap' map driver or a resulting MTD partition. |
| 48 | For example, this would mount the cramfs image stored in |
| 49 | the MTD partition named "xip_fs" on the /mnt mountpoint: |
| 50 | |
| 51 | mount -t cramfs mtd:xip_fs /mnt |
| 52 | |
| 53 | If unsure, say N. |