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
-
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