Re: initramfs buffer spec -- second draft

[Eric W. Biederman]

"H. Peter Anvin" <[e-mail]> writes:

> Eric W. Biederman wrote:
> 
> > Comments.  Endian issues are not specified, is the data little, big
> > or vax endian?
> >
> 
> 
> Not applicable.  There are no endian-specific binary structure in the format AT
> ALL.  ASCII-coded fields are always bigendian.

O.k.  Thanks, I missed that part.  I just looked back and it is clear
that there are 32 bit values encoded in hexadecimal.  And I admit the
bigendian (human readable) is strongly implied from the context.

> > What is the point of alignment?  If the data starts as 4 byte aligned,
> > the 6 byte magic string guarantees the data will be only 2 byte
> > aligned.  This isn't good for 32 or 64 bit architectures.
> 
> 
> They're ASCII-coded, so it supposedly doesn't matter (yet, it's a bit daft, but
> blame the SysV people.)  The alignment makes sure the *data* field is 4-byte
> aligned.

O.k.  So the we have a bit of implied padding after the filename.  And
it is necessary to preserve this padding or we break with the
prexisting format definition.  You don't gain much with that as being
4 byte aligned on 64bit architectures, is not fully aligned.

> > I do like having a c_magic that at least allows us to change things
> > in the future if necessary.
> 
> 
> It's pretty clear from a lot of the comments that a number of people haven't
> understood that the cpio encapsulation *THIS IS A CODIFICATION OF AN EXISTING
> FORMAT.*

Which we are reusing for a different purpose.  And because of that we
become trustees of our version of the format.  To make it clear that
someone else defines how this format works a reference to the
appropriate specification is called for.  

I admit I did a quick search earlier and I did not find this format
specified, elsewhere.

The cases where initramfs will be used are some of the most operating
specific cases I can imagine.  To handle those cases it is necessary
to support the full breadth of the capability of the operating system.
So if initramfs is going to survive todays implementation of the linux
kernel, or possibly be portable to other operating systems we must
have an extensible format.  It appears c_magic gives us that
extensibility.

Eric