On December 23, 2001 01:14, H. Peter Anvin wrote:
> It seems to me that this application doesn't really have a particular
> need for backward compatibility, nor for the I/O blocking stuff of
> tar/cpio. I would certainly be willing to write a set of portable
> utilities to create an archive in a custom format, if that would be more
> desirable. We'd still use gzip for compression, of course, and have the
> buffer composed as a combination of ".rfs" and ".rfs.gz" files,
> separated by zero-padding.
>
> What I'm talking about would probably still look a lot like the cpio
> header, but probably would use bigendian binary (bigendian because it
> allows the use of the widely portable htons() and htonl() macros), have
> explicit support for hard links, and not require a trailer block.
What about recycling a big-endian version of cramfs? IIRC, the format is
really clean, it already does compression, and is terse enough to be efficent
for booting purposes. However, it might be too terse as it:
1) Doesn't support hard links
2) Doesn't store atime/mtime/ctime
I don't know if that'd be too restrictive for an initrd replacement, but
having only one compressed-filesystemish filesystem for the kernel would be
nice.
-Ryan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Dec 23 2001 - 21:00:29 EST