Message-Id: <1201599251.5301.26.camel@localhost.localdomain>
Date:	Tue, 29 Jan 2008 09:34:11 +0000
From:	Ian Campbell <ijc@...lion.org.uk>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: PATCH/RFC: bzImage payload as compressed ELF file.


On Mon, 2008-01-28 at 14:54 -0800, Jeremy Fitzhardinge wrote:
> Ian Campbell wrote:
> > I'm mainly interested in something along these lines to allow the Xen
> > bootloader to load a bzImage so that distros don't have to maintain two
> > kernel packages with the same basic bits in different file formats, I
> > think it would probably be of use to the kexec and/or lguest folks too.
> >
> > The patch boots on native 32 and 64 bit x86. I haven't done the matching
> > Xen domain builder work but the attached bzexplode.c is a trivial/ugly
> > (don't judge me based on it ;-)) test app which extracts the payload,
> > which I have been able to boot as a 32 bit Xen domU, as you'd expect.
> >   
> 
> I've got a bzImage-loading domain builder patch somewhere.  It's based 
> on my version of what you've done here, which isn't very different.

Thanks, I'll probably make use of that patch when I come to do the
domain builder bits.

> The problem I ran into is that 32-bit boot loaders expect to be able to 
> load the payload portion of the bzImage and simply jmp 0x100000, which 
> would start executing the ELF header.

The payload I'm changing is the payload from the point of view of
arch/x86/boot/compressed -- i.e. piggy.o which becomes part of the
vmlinux in that directory (too many files called vmlinux!). I that might
more accurately be described that as the "payload of the payload" from
the point of view of a bzImage file or the "payload of the compressor
portion" or something.

If you strip of setup_sects (+1?) from a bzImage, which I think is what
you are referring above, then you end up with essentially
arch/x86/boot/compressed/vmlinux (at address 0x100000 from one of the
bzImage header fields) which can still be jumped to by a 32 bit
bootloader. It will decompress and process the ELF bits correctly. I
think this is where my patch differs from your previous version, you
made the actual compressor portion an ELF file within the bzImage.

The thing which no longer works here is scanning the whole image looking
for a gzip header just past setup_sects and extracting that expecting to
find a raw binary because you will actually find an ELF file. I'm not
sure that's an "interface" which could be expected to continue to work
for all time anyway.

> > What would be the preferred way of allowing bootloaders/domain builders
> > to find the compressed payload? Tacking the offset from the end onto the
> > end as I have done for the moment seems pretty skanky...
> >   
> 
> The header format is extensible, so you just up the bootloader revision 
> and put the appropriate extra members.

That's what I figured. There will be some build system pain to extract
those offsets from boot/compressed/vmlinux and incorporate them into
boot/bzImage but I'll figure something out.

Ian.

-- 
Ian Campbell
Current Noise: Centurions Ghost - Specimen No.7

Psychoanalysis is that mental illness for which it regards itself a
therapy.
		-- Karl Kraus

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

Powered by blists - more mailing lists