mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-11-24 15:31:14 +07:00
a8c6db00bf
Commitb9f5fb1800("cramfs: fix MTD dependency") did what it says. Since commit9059a3493e("kconfig: fix relational operators for bool and tristate symbols") it is possible to do it slightly better though. Signed-off-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
54 lines
2.1 KiB
Plaintext
54 lines
2.1 KiB
Plaintext
config CRAMFS
|
|
tristate "Compressed ROM file system support (cramfs)"
|
|
select ZLIB_INFLATE
|
|
help
|
|
Saying Y here includes support for CramFs (Compressed ROM File
|
|
System). CramFs is designed to be a simple, small, and compressed
|
|
file system for ROM based embedded systems. CramFs is read-only,
|
|
limited to 256MB file systems (with 16MB files), and doesn't support
|
|
16/32 bits uid/gid, hard links and timestamps.
|
|
|
|
See <file:Documentation/filesystems/cramfs.txt> and
|
|
<file:fs/cramfs/README> for further information.
|
|
|
|
To compile this as a module, choose M here: the module will be called
|
|
cramfs. Note that the root file system (the one containing the
|
|
directory /) cannot be compiled as a module.
|
|
|
|
This filesystem is limited in capabilities and performance on
|
|
purpose to remain small and low on RAM usage. It is most suitable
|
|
for small embedded systems. If you have ample RAM to spare, you may
|
|
consider a more capable compressed filesystem such as SquashFS
|
|
which is much better in terms of performance and features.
|
|
|
|
If unsure, say N.
|
|
|
|
config CRAMFS_BLOCKDEV
|
|
bool "Support CramFs image over a regular block device" if EXPERT
|
|
depends on CRAMFS && BLOCK
|
|
default y
|
|
help
|
|
This option allows the CramFs driver to load data from a regular
|
|
block device such a disk partition or a ramdisk.
|
|
|
|
config CRAMFS_MTD
|
|
bool "Support CramFs image directly mapped in physical memory"
|
|
depends on CRAMFS && CRAMFS <= MTD
|
|
default y if !CRAMFS_BLOCKDEV
|
|
help
|
|
This option allows the CramFs driver to load data directly from
|
|
a linear adressed 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.
|
|
|
|
The location of the CramFs image is determined by a
|
|
MTD device capable of direct memory mapping e.g. from
|
|
the 'physmap' map driver or a resulting MTD partition.
|
|
For example, this would mount the cramfs image stored in
|
|
the MTD partition named "xip_fs" on the /mnt mountpoint:
|
|
|
|
mount -t cramfs mtd:xip_fs /mnt
|
|
|
|
If unsure, say N.
|