Here comes a couple of patches to improve and fix problems in cramfs and
the tools mkcramfs and cramfsck.
The patches will be in seperate mails as below and are against
2.4.19-pre7 or the latest version from
http://sourceforge.net/projects/cramfs/
but will probably apply to 2.5 as well (and it really should go in there
as well).
1. Support for fstime and EDITION_TIMESTAMP in cramfs include files.
Uses the edition field in fsid if the CRAMFS_FLAG_EDITION_TIMESTAMP
flag is set.
2. Support for fstime in fs/cramfs/inode.c together with
fixing hardcoded blocksize conversion
(Now uses /(PAGE_CACHE_SIZE/1024) instead of >> 2).
3. The tools: mkcramfs.c and cramfsck.c: Add support for timestamp in the
edition field (fstime) and added the option -b blocksize.
For cramfsck.c it also fixes a segfault that occured in the error
message if the incorrect blocksize is used (order of arguments wrong).
4. The tools: mkcramfs.c gets added support for -m metafile option.
5. linux/Documentation/filesystems/metafiles.txt added that describes the
metafile format used in mkcramfs.
6. (RFC) In the cris architecture we have a hack that allows us
to append the cramfs image to the kernel image and use it to boot from.
We support both booting from flash where the kernel image is compressed
and the cramfs image is in flash and booting directly from RAM using
the image downloaded through the network interface - in that case the
kernel is not compressed and the cramfs image is in RAM after the kernel.
A special variable is used to determine which mode is used and
if we're booting from RAM, the cramfs is not read through a real
device.
I'll submit the patch for your amusement and welcomes any feedback.
An alternative approach could be to use a mtd-ram device but I don't
know how yet.
cram_fs_type and the read function should not be static since it is
accessed from do_mounts.c
/Johan
--- linux-2.4.19-pre7/include/linux/cramfs_fs.h Mon Apr 29 10:11:54 2002
+++ linux/include/linux/cramfs_fs.h Thu Apr 25 23:01:50 2002
@@ -49,7 +49,7 @@
struct cramfs_info {
u32 crc;
- u32 edition;
+ u32 edition; /* contains timestamp if EDITION_TIMESTAMP flag set */
u32 blocks;
u32 files;
};
@@ -76,6 +76,7 @@
*/
#define CRAMFS_FLAG_FSID_VERSION_2 0x00000001 /* fsid version #2 */
#define CRAMFS_FLAG_SORTED_DIRS 0x00000002 /* sorted dirs */
+#define CRAMFS_FLAG_EDITION_TIMESTAMP 0x00000004 /* fstime in edition */
#define CRAMFS_FLAG_HOLES 0x00000100 /* support for holes */
#define CRAMFS_FLAG_WRONG_SIGNATURE 0x00000200 /* reserved */
#define CRAMFS_FLAG_SHIFTED_ROOT_OFFSET 0x00000400 /* shifted root fs */
--- linux-2.4.19-pre7/include/linux/cramfs_fs_sb.h Mon Apr 29 10:11:54 2002
+++ linux/include/linux/cramfs_fs_sb.h Mon Apr 29 10:26:11 2002
@@ -5,11 +5,12 @@
* cramfs super-block data in memory
*/
struct cramfs_sb_info {
- unsigned long magic;
- unsigned long size;
- unsigned long blocks;
- unsigned long files;
- unsigned long flags;
+ unsigned long magic;
+ unsigned long size;
+ unsigned long blocks;
+ unsigned long files;
+ unsigned long flags;
+ time_t fstime; /* From the edition field if EDITION_TIMESTAMP */
};
#endif
Johan Adolfsson writes:
> 1. Support for fstime and EDITION_TIMESTAMP in cramfs include files.
> Uses the edition field in fsid if the CRAMFS_FLAG_EDITION_TIMESTAMP
> flag is set.
> 2. Support for fstime in fs/cramfs/inode.c together with
> fixing hardcoded blocksize conversion
> (Now uses /(PAGE_CACHE_SIZE/1024) instead of >> 2).
> 3. The tools: mkcramfs.c and cramfsck.c: Add support for timestamp in the
> edition field (fstime) and added the option -b blocksize.
> For cramfsck.c it also fixes a segfault that occured in the error
> message if the incorrect blocksize is used (order of arguments wrong).
These first three look good. I made a few minor changes and merged it
with the big-endian patch, so I'll send you my current version before
sending it onwards to Marcelo and Linus.
The big-endian patch was waiting for 2.4.19 to be released, but maybe I
should just submit it if 2.4.19 is going to be a while. Also, all of
the big-endian changes are checked into the CVS tree now.
Dan
----- Original Message -----
From: "Daniel Quinlan" <[email protected]>
> These first three look good.
Any particular doughts about the metafile stuff or do you just need
some more time to look at it?
Unless I screwed something subtle up in the merge, it has been
working fine for us in production use for more then a year or so,
we have the same thing in our mkfs.jffs, genromfs and a patch for
mkfs.jffs2 as well I think.
> I made a few minor changes and merged it
> with the big-endian patch, so I'll send you my current version before
> sending it onwards to Marcelo and Linus.
>
> The big-endian patch was waiting for 2.4.19 to be released, but maybe I
> should just submit it if 2.4.19 is going to be a while. Also, all of
> the big-endian changes are checked into the CVS tree now.
Great, I say: "go for it!" and try to get it in before 2.4.19,
it's rather small and clean.
> Dan
/Johan