From: Nicolas Pitre <nicolas.pitre@linaro.org> To: Alexander Viro <viro@zeniv.linux.org.uk>, linux-mm@kvack.org Cc: linux-fsdevel@vger.kernel.org, linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Brandt <Chris.Brandt@renesas.com> Subject: [PATCH v4 5/5] cramfs: rehabilitate it Date: Wed, 27 Sep 2017 19:32:24 -0400 [thread overview] Message-ID: <20170927233224.31676-6-nicolas.pitre@linaro.org> (raw) In-Reply-To: <20170927233224.31676-1-nicolas.pitre@linaro.org> Update documentation, pointer to latest tools, appoint myself as maintainer. Given it's been unloved for so long, I don't expect anyone will protest. Signed-off-by: Nicolas Pitre <nico@linaro.org> Tested-by: Chris Brandt <chris.brandt@renesas.com> --- Documentation/filesystems/cramfs.txt | 42 ++++++++++++++++++++++++++++++++++++ MAINTAINERS | 4 ++-- fs/cramfs/Kconfig | 9 +++++--- 3 files changed, 50 insertions(+), 5 deletions(-) diff --git a/Documentation/filesystems/cramfs.txt b/Documentation/filesystems/cramfs.txt index 4006298f67..8875d306bc 100644 --- a/Documentation/filesystems/cramfs.txt +++ b/Documentation/filesystems/cramfs.txt @@ -45,6 +45,48 @@ 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_PHYSMEM Kconfig option adds support for loading data directly +from a physical linear memory range (usually non volatile memory like Flash) +to cramfs 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 filesystem type for this feature is "cramfs_physmem" to distinguish it +from the block device (or MTD) based access. 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 specify it using the +physaddr=0x******** mount option (for example, if the physical address +of the cramfs image is 0x80100000, the following command would mount it +on /mnt: + +$ mount -t cramfs_physmem -o physaddr=0x80100000 none /mnt + +To boot such an image as the root filesystem, the following kernel +commandline parameters must be provided: + + "rootfstype=cramfs_physmem rootflags=physaddr=0x80100000" + + +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 -------------------- diff --git a/MAINTAINERS b/MAINTAINERS index 1c3feffb1c..f00aec6a66 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3612,8 +3612,8 @@ F: drivers/cpuidle/* F: include/linux/cpuidle.h CRAMFS FILESYSTEM -W: http://sourceforge.net/projects/cramfs/ -S: Orphan / Obsolete +M: Nicolas Pitre <nico@linaro.org> +S: Maintained F: Documentation/filesystems/cramfs.txt F: fs/cramfs/ diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig index 306549be25..374d52e029 100644 --- a/fs/cramfs/Kconfig +++ b/fs/cramfs/Kconfig @@ -1,5 +1,5 @@ config CRAMFS - tristate "Compressed ROM file system support (cramfs) (OBSOLETE)" + tristate "Compressed ROM file system support (cramfs)" select ZLIB_INFLATE help Saying Y here includes support for CramFs (Compressed ROM File @@ -15,8 +15,11 @@ config CRAMFS cramfs. Note that the root file system (the one containing the directory /) cannot be compiled as a module. - This filesystem is obsoleted by SquashFS, which is much better - in terms of performance and features. + 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. For a more capable compressed filesystem + you should look at SquashFS which is much better in terms of + performance and features. If unsure, say N. -- 2.9.5
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Pitre <nicolas.pitre@linaro.org> To: Alexander Viro <viro@zeniv.linux.org.uk>, linux-mm@kvack.org Cc: linux-fsdevel@vger.kernel.org, linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Brandt <Chris.Brandt@renesas.com> Subject: [PATCH v4 5/5] cramfs: rehabilitate it Date: Wed, 27 Sep 2017 19:32:24 -0400 [thread overview] Message-ID: <20170927233224.31676-6-nicolas.pitre@linaro.org> (raw) In-Reply-To: <20170927233224.31676-1-nicolas.pitre@linaro.org> Update documentation, pointer to latest tools, appoint myself as maintainer. Given it's been unloved for so long, I don't expect anyone will protest. Signed-off-by: Nicolas Pitre <nico@linaro.org> Tested-by: Chris Brandt <chris.brandt@renesas.com> --- Documentation/filesystems/cramfs.txt | 42 ++++++++++++++++++++++++++++++++++++ MAINTAINERS | 4 ++-- fs/cramfs/Kconfig | 9 +++++--- 3 files changed, 50 insertions(+), 5 deletions(-) diff --git a/Documentation/filesystems/cramfs.txt b/Documentation/filesystems/cramfs.txt index 4006298f67..8875d306bc 100644 --- a/Documentation/filesystems/cramfs.txt +++ b/Documentation/filesystems/cramfs.txt @@ -45,6 +45,48 @@ 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_PHYSMEM Kconfig option adds support for loading data directly +from a physical linear memory range (usually non volatile memory like Flash) +to cramfs 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 filesystem type for this feature is "cramfs_physmem" to distinguish it +from the block device (or MTD) based access. 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 specify it using the +physaddr=0x******** mount option (for example, if the physical address +of the cramfs image is 0x80100000, the following command would mount it +on /mnt: + +$ mount -t cramfs_physmem -o physaddr=0x80100000 none /mnt + +To boot such an image as the root filesystem, the following kernel +commandline parameters must be provided: + + "rootfstype=cramfs_physmem rootflags=physaddr=0x80100000" + + +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 -------------------- diff --git a/MAINTAINERS b/MAINTAINERS index 1c3feffb1c..f00aec6a66 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3612,8 +3612,8 @@ F: drivers/cpuidle/* F: include/linux/cpuidle.h CRAMFS FILESYSTEM -W: http://sourceforge.net/projects/cramfs/ -S: Orphan / Obsolete +M: Nicolas Pitre <nico@linaro.org> +S: Maintained F: Documentation/filesystems/cramfs.txt F: fs/cramfs/ diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig index 306549be25..374d52e029 100644 --- a/fs/cramfs/Kconfig +++ b/fs/cramfs/Kconfig @@ -1,5 +1,5 @@ config CRAMFS - tristate "Compressed ROM file system support (cramfs) (OBSOLETE)" + tristate "Compressed ROM file system support (cramfs)" select ZLIB_INFLATE help Saying Y here includes support for CramFs (Compressed ROM File @@ -15,8 +15,11 @@ config CRAMFS cramfs. Note that the root file system (the one containing the directory /) cannot be compiled as a module. - This filesystem is obsoleted by SquashFS, which is much better - in terms of performance and features. + 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. For a more capable compressed filesystem + you should look at SquashFS which is much better in terms of + performance and features. If unsure, say N. -- 2.9.5 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-09-27 23:33 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-09-27 23:32 [PATCH v4 0/5] cramfs refresh for embedded usage Nicolas Pitre 2017-09-27 23:32 ` Nicolas Pitre 2017-09-27 23:32 ` [PATCH v4 1/5] cramfs: direct memory access support Nicolas Pitre 2017-09-27 23:32 ` Nicolas Pitre 2017-10-01 8:29 ` Christoph Hellwig 2017-10-01 8:29 ` Christoph Hellwig 2017-10-01 22:27 ` Nicolas Pitre 2017-10-01 22:27 ` Nicolas Pitre 2017-10-03 14:59 ` Christoph Hellwig 2017-10-03 14:59 ` Christoph Hellwig 2017-10-03 15:06 ` Nicolas Pitre 2017-10-03 15:06 ` Nicolas Pitre 2017-10-03 14:43 ` Rob Herring 2017-10-03 14:43 ` Rob Herring 2017-10-03 14:58 ` Chris Brandt 2017-10-03 14:58 ` Chris Brandt 2017-09-27 23:32 ` [PATCH v4 2/5] cramfs: make cramfs_physmem usable as root fs Nicolas Pitre 2017-09-27 23:32 ` Nicolas Pitre 2017-09-27 23:32 ` [PATCH v4 3/5] cramfs: implement uncompressed and arbitrary data block positioning Nicolas Pitre 2017-09-27 23:32 ` Nicolas Pitre 2017-09-27 23:32 ` [PATCH v4 4/5] cramfs: add mmap support Nicolas Pitre 2017-09-27 23:32 ` Nicolas Pitre 2017-10-01 8:30 ` Christoph Hellwig 2017-10-01 8:30 ` Christoph Hellwig 2017-10-01 22:29 ` Nicolas Pitre 2017-10-01 22:29 ` Nicolas Pitre 2017-10-02 22:45 ` Richard Weinberger 2017-10-02 22:45 ` Richard Weinberger 2017-10-02 23:33 ` Nicolas Pitre 2017-10-02 23:33 ` Nicolas Pitre 2017-10-03 14:57 ` Christoph Hellwig 2017-10-03 14:57 ` Christoph Hellwig 2017-10-03 15:30 ` Nicolas Pitre 2017-10-03 15:30 ` Nicolas Pitre 2017-10-03 15:37 ` Christoph Hellwig 2017-10-03 15:37 ` Christoph Hellwig 2017-10-03 15:40 ` Nicolas Pitre 2017-10-03 15:40 ` Nicolas Pitre 2017-10-04 7:25 ` Christoph Hellwig 2017-10-04 7:25 ` Christoph Hellwig 2017-10-04 20:47 ` Nicolas Pitre 2017-10-04 20:47 ` Nicolas Pitre 2017-10-05 7:15 ` Christoph Hellwig 2017-10-05 7:15 ` Christoph Hellwig 2017-10-05 17:52 ` Nicolas Pitre 2017-10-05 17:52 ` Nicolas Pitre 2017-10-05 20:00 ` Chris Brandt 2017-10-05 20:00 ` Chris Brandt 2017-10-05 21:15 ` Nicolas Pitre 2017-10-05 21:15 ` Nicolas Pitre 2017-10-05 23:49 ` Chris Brandt 2017-10-05 23:49 ` Chris Brandt 2017-09-27 23:32 ` Nicolas Pitre [this message] 2017-09-27 23:32 ` [PATCH v4 5/5] cramfs: rehabilitate it Nicolas Pitre
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170927233224.31676-6-nicolas.pitre@linaro.org \ --to=nicolas.pitre@linaro.org \ --cc=Chris.Brandt@renesas.com \ --cc=linux-embedded@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.