[lkml]   [2002]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: initramfs buffer spec -- second draft
    Alexander Viro <> writes:

    > On 13 Jan 2002, Eric W. Biederman wrote:
    > > 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.
    > We are using it for precisely the same purpose - to put a bunch of
    > files on a filesystem.

    Anytime you are specifying semantics beyond what was in the original
    specification it isn't precisely the same case. Close enough not to
    matter yes but not precisely the same. The original cpio format does
    not specify compression or concatenation of images. It is not
    mandated that the cpio format handle the needs of everyones root

    Additionally we now have the potential of generating cpio files from
    the bootloaders. And bootloaders should be the kinds of programs that
    don't need constant maintenance or upgrading, (that is very
    destabilizing). So totally reworking the format is not a solution
    when we need to change something. Even if is ok for cpio in general.

    This changing the format in incompatible ways when there is a new
    requirement does seem to be the traditional cpio method.

    > > 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.
    > Huh? It's a bloody archive - collection of files and nothing else.
    > What "capability of the operating system"?

    Exactly. But the standard unix stream of bytes does not cover everyones
    concept of files. Things like:
    Symbolic Links
    Device Nodes,
    Resource Forks,
    Device links,
    Persistent mount points,
    Persistent capabilities,

    Are all partial exceptions to everything is the same kind of file.
    The cpio format as is doesn't handle all of these which is fine, but
    we may need some of these later, so we need someplace to expand to
    when if/when these kinds of things become important.

    The startup process is likely to need everything the operating system
    can do, to handle some special case or the other. So if at some
    future date we support odd types of special files we will probably
    need to use them in the system startup code. We already require device
    nodes, and find symbolic links very helpful.

    Further Linux is dynamic and always changing, so not having some elbow
    room for growth is just asking for trouble. All I noted is that
    the c_magic field exists so if/when the need arises we can handle
    really strange cases. With everyone in linux being able to use an
    initramfs as their root filesystem actually makes the odds of a change
    that requires special root filesystem support much more likely.
    Because you only have to change one filesystem.

    All I am asking is two things. If we are not assuming guardianship
    for our variant of the cpio format we should reference those who do
    have guardianship, in the specification. We should be aware that the
    cpio format as it now exists may not handle all future needs so
    having a mechanism to extend the format when those needs arise without
    breaking all existing users is important.

    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:15    [W:0.031 / U:30.900 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site