From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Korsgaard Date: Sun, 27 Jun 2010 22:02:32 +0200 Subject: [Buildroot] [git commit master 1/1] initramfs: update help text In-Reply-To: <20100627093056.5635ce90@surf> (Thomas Petazzoni's message of "Sun, 27 Jun 2010 09:30:56 +0200") References: <20100626054529.9E7CE81E0B@busybox.osuosl.org> <87aaqh38vi.fsf@macbook.be.48ers.dk> <87hbkp3sfz.fsf@macbook.be.48ers.dk> <20100627093056.5635ce90@surf> Message-ID: <87aaqg452f.fsf@macbook.be.48ers.dk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net >>>>> "Thomas" == Thomas Petazzoni writes: Thomas> On Sun, 27 Jun 2010 08:22:56 +0200 Thomas> Peter Korsgaard wrote: >> No, but you could extract the tarball (as root or using fakeroot) and >> point CONFIG_INITRAMFS_SOURCE to it. >> >> But yes, providing a way to generate the cpio archive without building a >> kernel would be nicer. 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. So what is the difference between initramfs and cpio? Just the integration with the kernel build for the first? Maybe the initramfs stuff should simply be a 'embed in kernel' question on the cpio package if the internal kernel build is enabled? Thomas> Instead of my original solution, another solution would be to Thomas> *not* make initramfs depend on BR2_LINUX_KERNEL, and to remove Thomas> the dependency initramfs-> kernel so that the kernel doesn't Thomas> try to be built as soon as initramfs is selected. If kernel is Thomas> selected, it will anyway be built *before* going through the Thomas> initramfs code. Thomas> Would this be ok ? What would then be the difference between this and the cpio target? -- Bye, Peter Korsgaard