From: "H. Peter Anvin" <hpa@zytor.com>
To: Alexander Viro <viro@math.psu.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: tar vs cpio (was: Booting a modular kernel through a multiple streams file)
Date: Sun, 23 Dec 2001 01:14:21 -0800 [thread overview]
Message-ID: <3C25A06D.7030408@zytor.com> (raw)
In-Reply-To: <Pine.GSO.4.21.0112222109050.21702-100000@weyl.math.psu.edu>
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:
a) Several different formats; <cpio.h> only documents one of them; I
have only found info on that one so some of these things may not apply.
b) No obvious ways to handle hard links, that doesn't require you
keeping a table of the inode numbers already seen (at least for which
c_nlink > 1) and hard link to them on the decompression side. Since we
have an assymetric setup, it seems like its done at the wrong end.
c) The use of TRAILER!!! as an end-of-archive marker (first, it's a
valid name, and second, there shouldn't be a need for an end-of-archive
marker in this application as long as each individual file is
self-terminating thus returning the dearchiver to its ground state. If
we stick with cpio, I would like these entries to have no effect.
d) c_rdev, c_uid, c_gid, c_dev, and c_ino are too small, at least in the
<cpio.h> format.
e) The use of octal ASCII numbers is somewhat ugly.
f) No ctime, no atime.
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
next prev parent reply other threads:[~2001-12-23 9:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-17 22:10 Booting a modular kernel through a multiple streams file Grover, Andrew
2001-12-18 2:31 ` Alexander Viro
2001-12-18 5:46 ` Craig Christophel
2001-12-23 0:28 ` Dave Cinege
2001-12-23 0:44 ` Dave Cinege
2001-12-23 1:39 ` H. Peter Anvin
2001-12-23 2:10 ` Alexander Viro
2001-12-23 3:00 ` Dave Cinege
2001-12-23 3:52 ` Alexander Viro
2001-12-23 4:41 ` Ryan Cumming
2001-12-23 5:52 ` Dave Cinege
2001-12-23 7:16 ` Bernd Eckenfels
2001-12-23 8:06 ` H. Peter Anvin
2001-12-23 12:22 ` Kai Henningsen
2001-12-23 20:58 ` Erik Mouw
2001-12-23 9:14 ` H. Peter Anvin [this message]
2001-12-22 19:53 ` tar vs cpio (was: Booting a modular kernel through a multiple streams file) T. A.
2001-12-23 19:17 ` H. Peter Anvin
2001-12-23 9:51 ` Ryan Cumming
2001-12-23 9:53 ` H. Peter Anvin
2001-12-23 12:01 ` Wichert Akkerman
2001-12-23 14:28 ` Alexander Viro
2001-12-23 19:28 ` H. Peter Anvin
2001-12-23 20:00 ` H. Peter Anvin
2001-12-18 15:26 ` Booting a modular kernel through a multiple streams file / Making Linux multiboot capable and grub loading kernel modules at boot time Christian Koenig
2001-12-18 18:32 ` H. Peter Anvin
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=3C25A06D.7030408@zytor.com \
--to=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@math.psu.edu \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox