LKML Archive on
help / color / mirror / Atom feed
From: Ian Campbell <>
To: Jeremy Fitzhardinge <>
Cc: "H. Peter Anvin" <>,,
	"Eric W. Biederman" <>
Subject: Re: PATCH/RFC: bzImage payload as compressed ELF file.
Date: Tue, 29 Jan 2008 09:34:11 +0000	[thread overview]
Message-ID: <1201599251.5301.26.camel@localhost.localdomain> (raw)
In-Reply-To: <>

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 Campbell
Current Noise: Centurions Ghost - Specimen No.7

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

  reply	other threads:[~2008-01-29  9:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-28 22:42 Ian Campbell
2008-01-28 22:54 ` Jeremy Fitzhardinge
2008-01-29  9:34   ` Ian Campbell [this message]
2008-01-29 17:54     ` Jeremy Fitzhardinge
2008-01-29 18:05       ` H. Peter Anvin
2008-01-29 18:31         ` Jeremy Fitzhardinge
2008-01-29 18:34           ` H. Peter Anvin
2008-01-29 20:38             ` Ian Campbell
2008-01-29 21:50               ` H. Peter Anvin
2008-01-29 21:55                 ` Ian Campbell
2008-01-29 22:09                   ` H. Peter Anvin
2008-01-28 23:20 ` H. Peter Anvin
2008-01-29  9:31   ` Ian Campbell
2008-02-01 13:10 ` Ingo Molnar
2008-02-01 18:05   ` H. Peter Anvin
2008-02-01 18:15     ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1201599251.5301.26.camel@localhost.localdomain \ \ \ \ \ \
    --subject='Re: PATCH/RFC: bzImage payload as compressed ELF file.' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).