[lkml]   [2002]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: initramfs buffer spec -- second draft
    On January 13, 2002 09:39 pm, Alexander Viro wrote:
    > On 13 Jan 2002, Eric W. Biederman wrote:
    > > "H. Peter Anvin" <> 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?


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:23    [W:0.024 / U:106.340 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site