Re: tar vs cpio (was: Booting a modular kernel through a multiple streams file)

[Ryan Cumming]

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