public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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