Re: [PATCH 1/2] lib: Add early cpio decoder

[Thomas Renninger <trenn@suse.de>]

On Tuesday, September 04, 2012 07:00:09 PM H. Peter Anvin wrote:
> On 08/30/2012 02:29 AM, Thomas Renninger wrote:
> > From: "H. Peter Anvin" <hpa@linux.intel.com>
> >
> > Add a simple cpio decoder without library dependencies for the purpose
> > of extracting components from the initramfs blob for early kernel
> > uses.  Intended consumers so far are microcode and ACPI override.
> >
> > Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
> > CC: Thomas Renninger <trenn@suse.de>
> > Link: http://lkml.kernel.org/r/201203261651.29640.trenn@suse.de
> > Signed-off-by: Thomas Renninger <trenn@suse.de>
> 
> I was trying to figure out if there is a way to do what you want 
> (support for multiple files) without the problems of the callback 
> interface.  I think it is actually fairly straightforward; we need a 
> prefix iterator (so you can give it a string like "kernel/acpi/" rather 
> than a full filename) and it needs to be able to accept a "last" pointer 
> so it can resume scanning at the point it last left off.  That should be 
> a pretty trivial change.
Yep, this is a good idea.
 
> The other thing we presumably want to do -- and this is generic -- is to 
> be able to handle multiple sources for the initramfs; at the very least 
> there is built in vs provided from the boot loader.  I had originally 
> intended to just handle that by calling the earlycpio function once per 
> block, but the "last left off" bit makes that a little harder.  Need to 
> think about that a little bit.
I guess I understand the first part, not sure about the "last left off" 
bit.
"Multiple sources" means bootloader already points to multiple sources,
right?
This is somewhat out of scope as this would need both, bootloader and
kernel adjustings.
This is about "built in" which means multiple cpios concatenated together
and passed via bootloader as one "file" (initrd).
At least I understand it that way.
The only disadvantage I run into is that once the cpios are concatenated,
I couldn't figure out an easy way how to slice them into separate
cpio/zip archives again.

> I am guessing that this may not need to be something we need from the 
> very beginning, or am I wrong?

I have re-worked the patches:
  - added an offset argument to be able to iterate over files inside
    a directory as suggested
  - removed the strlen and memcmp function duplication in earlycpio.c
    This is not needed for this patchset and would be confusing.
    This can easily be added in the context of the patches which need it

I'll re-submit.

Thanks,

   Thomas