Re: tip: bzip2/lzma now in tip:x86/setup-lzma

[Willy Tarreau]

On Wed, Feb 18, 2009 at 11:52:47AM -0800, H. Peter Anvin wrote:
> Alain Knaff wrote:
> >
> >Maybe another solution would be to make the choice of builtin ramdisk
> >compression user-selectable, and default to no compression at all.
> >
> 
> That might just make most sense.
> 
> >Indeed, in the default case, the builtin ramdisk is so small (950 bytes
> >uncompressed), that it probably wouldn't really matter anyways.
> >
> >The only case where it matters is for developers of embedded systems who
> >want to replace the builtin ramdisk with a fully populated one, because
> >their boot loader does not support loading a "normal" initrd.
> >
> >These people are (hopefully) knowledgeable enough to pick an appropriate
> >compressor (but there's still the issue of notifying them about the
> >change, obviously).
> >
> >Btw, what *is* the standard work flow of supplying your own built-in
> >initramfs? Do such developers usually supply a directory tree, or do
> >they already cpio it before supplying it to the kernel? Or do they even
> >compress it themselves?
> 
> The normal thing is that you point the kernel build to an 
> out-of-the-kernel-build-tree directory.

FWIW I'm personally used to include my kernel's modules into its own
initramfs, so that I can have a common generic rootfs image in a
separate initrd and multiple kernels using the same initrd. This
allows me to easily and quickly boot full-featured kernels from CD,
USB sticks or even PXE, load modules depending on my usages, and
only have to care about some kernel build options (typically SMP/UP)
without having to repackage anything in the root fs. This brings me
the best of modules and monolithic kernels, and that's very convenient.

The build process is not trivial, as I have to proceed in two steps
to package the kernel's own modules into the initramfs before building
the final vmlinux. But scripts make that easier.

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/