lkml.org 
[lkml]   [2002]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: initramfs buffer spec -- second draft
Date
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

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

\
 
 \ /
  Last update: 2005-03-22 13:23    [W:0.237 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site