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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090218210917.GQ5038@1wt.eu>
Date:	Wed, 18 Feb 2009 22:09:17 +0100
From:	Willy Tarreau <w@....eu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Alain Knaff <alain@...ff.lu>, Ingo Molnar <mingo@...e.hu>,
	Jan Engelhardt <jengelh@...ozas.de>,
	the arch/x86 maintainers <x86@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: tip: bzip2/lzma now in tip:x86/setup-lzma

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/