Re: initramfs buffer spec -- second draft

[Daniel Phillips <phillips@bonn-fries.net>]

On January 13, 2002 09:39 pm, Alexander Viro wrote:
> On 13 Jan 2002, Eric W. Biederman wrote:
> 
> > "H. Peter Anvin" <hpa@zytor.com> writes:
> > 
> > > This is an update to the initramfs buffer format spec I posted
> > > earlier.  The changes are as follows:
> > 
> > Comments.  Endian issues are not specified, is the data little, big
> > or vax endian?
> 
> Data is what you put into files, byte-by-byte.  Headers are ASCII.

In a perfect world we would settle of one of big or little-endian and 
byte-swap as appropriate, as we do with, e.g., Ext2 filesystems.  However it 
seems that cpio in its current form has no concept of byte-swapping.  Cpio(1) 
can neither generate nor decode a cpio file in the 'foreign' byte sex.  So if 
we are determined to use cpio as it stands, then we are stuck with the goofy 
ASCII encoding, does that sum up the situation?

Too bad about that, otherwise cpio seems quite reasonable.

I just can't get over those ascii encoding though, and I can't shake the 
feeling that relying on never having a file named TRAILER!!! is strange.  
It's gratuitous pollution of the namespace.

What was the reason for going with cpio again - so we can use standard tools? 
How hard would it be to fix cpio to get rid of the warts?  What would we 
break?  Is the problem that we would have to, ugh, go into user space or, 
eww, cooperate with non-kernel developers?

--
Daniel