[Buildroot] [git commit master 1/1] initramfs: update help text

[Grant Edwards <grant.b.edwards@gmail.com>]

On 2010-06-27, Peter Korsgaard <jacmet@sunsite.dk> wrote:
>>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes:
>
> Hi,
>
>  Thomas> Well, a cpio archive can be generated by Buildroot without having to
>  Thomas> build a kernel, see fs/cpio/Config.in. What Grant was complaining about
>  Thomas> originally was the fs/initramfs case. However, last time I tried
>  Thomas> pointing CONFIG_INITRAMFS_SOURCE to a cpio archive, it didn't work.
>
> Peter> So what is the difference between initramfs and cpio? Just the
> Peter> integration with the kernel build for the first? Maybe the initramfs
> Peter> stuff should simply be a 'embed in kernel' question on the cpio package
> Peter> if the internal kernel build is enabled?
>
> Ok, looked a bit closer and noticed that the initramfs target doesn't
> actually create a cpio, but a command file for gen_init_cpio.

Right.  But why does that require building a kernel?  It's just a list
of files/nodes that goes into the cpio archive.  If you're allowed to
build a cpio archive or a tar archive, surely you should be allowed to
build the list of files that goes into the archive?

> Nevertheless, is there any advantage to use that instead of just
> creating a cpio archive (besides it not working for you somehow)?

If the cpio archive works, then I'm happy.  For no particular reason
I've always used the file-list method in the past.  I tried building
the kernel with the cpio archive instead, and the build worked fine.
But, my target HW seems go have gone walkabout for a few days, so I
haven't been able to test the impage built with the cpio archive
instead of the source file list.

You can point the kernel at an unpacked directory tree, but that's
undesirable since the unpacking has to be done as root (right?).  At
least that's what I remember.

-- 
Grant