[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1207477344.28696.25.camel@localhost.localdomain>
Date: Sun, 06 Apr 2008 11:22:24 +0100
From: Ian Campbell <ijc@...lion.org.uk>
To: Yinghai Lu <yhlu.kernel@...il.com>
Cc: Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Jeremy Fitzhardinge <jeremy@...p.org>,
virtualization@...ts.linux-foundation.org
Subject: Re: [PATCHv3 1/3] x86: use ELF format in compressed images.
On Sun, 2008-04-06 at 00:03 -0700, Yinghai Lu wrote:
> so will cost every bzImage extra memory copy? that could be 18M or
> even more big.
Is it a huge deal for something that happens exactly once on boot? How
does the time take compare with the time to do the decompression?
18M seems like an awfully large kernel image to me. My distro (Debian)
kernel is more like 3M uncompressed. If someone was interested in fast
booting presumably they would either build a kernel with exactly what
they need.
> wonder if can have one some other kind elf format, and offset load
> address to avoid that mem copy.
I guess you could reduce the load address by sizeof(headers) and add a
dest == (output + phdr->p_offset) test before the copy.
Another possibility, which is much more complex, is that the ELF parsing
could be integrated into the decompressor such that the data is
decompressed into the correct location directly.
Ian.
--
Ian Campbell
People who have no faults are terrible; there is no way of taking
advantage of them.
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists