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

["T. A." <tkhoadfdsaf@hotmail.com>]

    What about considering one of the simpler filesystems or archive formats
instead?  How much "Unix"-ism is required to be retained in the archive?
(permissions, device files, etc?)

    As for the bigendianness... Is it really relevant since each kernel is
tied to its own platform?  And if it is may it be better to use the native
format of the 98% or so of the Linux machines out there which are
littleendian (performance and ease of general access on the majority of host
machines comes to mind).

----- Original Message -----
From: "H. Peter Anvin" <hpa@zytor.com>
To: "Alexander Viro" <viro@math.psu.edu>
Cc: <linux-kernel@vger.kernel.org>
Sent: Sunday, December 23, 2001 4:14 AM
Subject: Re: tar vs cpio (was: Booting a modular kernel through a multiple
streams file)


> I have looked through the various forms of tar and cpio, and I'm getting
> the feeling that both are ugly as hell for the purpose of initializing
> initramfs.  The block-based setup of tar (and of the new Austin group
> "pax" format -- really just a new rev of tar) is awful, but some of the
> tape-oriented aspects of cpio isn't much better.  What concerns me about
> cpio in particular:
> 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.
>
> -hpa
>
> -
> 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/
>