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: <alpine.LSU.2.00.0902181127310.30241@fbirervta.pbzchgretzou.qr>
Date:	Wed, 18 Feb 2009 11:29:51 +0100 (CET)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Alain Knaff <alain@...ff.lu>
cc:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	the arch/x86 maintainers <x86@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: tip: bzip2/lzma now in tip:x86/setup-lzma


On Wednesday 2009-02-18 10:40, Alain Knaff wrote:
>> 
>> I would expect of *module* developers to build their code by means of
>> an out-of-tree directory, thereby not causing regeneration of the
>> vmlinux binary or initramfs image. Even if they stayed within the
>> Linux srctree, they could take a shortcut by explicitly stating the
>> target (`make that/foo.ko`). modpost is still something that takes
>> much more time with allmodconfig than compressing the kernel and/or
>> changed modules over and over.
>
>You are right of course for modules inserted by insmod modprobe. But what
>about people who tune parts that must be compiled-in (VFS layer, etc.), or
>that investigate a bug in a module that only occurs when it is compiled
>into the kernel?

The developer would then most likely just disable compression for
the time being.

>>[second topic]
>> As for me: a separate staging directory that is totally unrelated to
>> the Linux tree, and manually running the cpio command. And not
>> embodying it into the kernel because all bootloaders used so far
>> support reading an extra initramfs image.
>
>Interesting. If that is the case in general, for all developers of embedded
>systems, then we might be able to do away with compression of the built-in
>initramfs altogether, as proposed in the very early versions of my patch.

Even if it is true in general, I would not remove CONFIG_INITRAMFS_SOURCE
and attached logic, unless it were a major burden on the maintainers.
(I am not to quantify whether it is such a burden, or is not.)
--
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/