linux-kernel - Re: Patches for REALLY TINY 386 kernels

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]

Date:	Wed, 18 Jul 2007 20:42:39 +0200 (CEST)
From:	Jan Engelhardt <jengelh@...putergmbh.de>
To:	Adrian Bunk <bunk@...sta.de>
cc:	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
	Jonathan Campbell <jon@...dgrounds.com>,
	linux-kernel@...r.kernel.org, torvalds@...nsmeta.com
Subject: Re: Patches for REALLY TINY 386 kernels

On Jul 18 2007 20:33, Adrian Bunk wrote:
>> Well, how big the vmlinux file is matters if it doesn't fit in memory
>> with enough time to get to the phase where it is dumping the init
>> sections.  *If that is not the issue*, then axing stuff like CPUID is a
>> major lose in terms of code maintainability for zero gain.
>
>If this is an issue, then changing i386 back to discarding __exit code 
>and data at linktime instead of runtime might make a bigger difference.

Would not that be good in either case? (I.e. even beyond i386)
Discarding __exit at the linking stage for CONFIG_MODULES=n kernels
sounds really good, because it reduces the time to _load_ the kernel.
Think TFTP. Particularly SPARC OBPs (I've seen E250 and E10K do that)
do TFTP transfers like an old granny ... You wait roughly two minutes
for common Aurora and Debian images (around 6 to 7 MB) - to get the
picture. I am grateful for every kilobyte images can lose.

	Jan
-- 
-
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/