Re: [Xen-devel] RFC/Patch: Support for other bootloaders

[Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>]

On Wed, 2005-03-23 at 16:23 +0000, Tim Deegan wrote:
> On Wed, Mar 23, 2005 at 03:52:32PM -0000, Ian Pratt wrote:
> > [*] would it possible to do something whereby the vmlinuz and initrd
> > image were simply cat'ed together? This might swing the balance the
> > other way from a userbility POV, not sure.
> 
> It should be.  xen-vmlinux is an ELF, so if we can be *sure* that the
> largest file offset in an ELF header is the same as the size of the
> file, then it would be possible to just do
> 
>  $ cat vmlinux-xen0 initrd-xen0 >pseudo-initrd
> 
>  boot: xen pseudo-initrd.
> 
> and then have Xen root around in the ELF headers to see where the break
> is.
> 

Sure, you could do that.  You could also define, in Linux, two symbols
"initrd_start", "initrd_end".

Then, use objcopy to insert a ramdisk in between the two.  It's not
"cat", but you can just create a wrapper shell script around the
objcopy.

Linux then checks to see if the two symbols point to the same spot; if
they don't it's got a ramdisk embedded in it.

What you can actually do is this:

1.  Take a vmlinux and "load" it into a file (use objcopy to output
binary format).  Remember the entry point address!! (Entry point
instructions should be at the start of the file.)

2.  With a magic linker script, take the vmlinux.bin and initrd and
create a single ELF file, which contains two "LOAD" segments.

3.  A proper ELF loader will then load those two segments into memory.

Essentially, what I'm saying is that you can use ELF as the format for
the "meta-ramdisk".


> Suporting gzipped vmlinux should be possible too; Xen needs to unzip the
> kernel and then knows that the next byte after the gzipped input will be
> ramdisk.  (As long as the bootloader doesn't helfully unzip the
> 'ramdisk' for us.)
> 

Linux should be able to unzip the ramdisk itself.  I thought it could
already do that.

> Michal, what do you think?  It sounds like this could be added to your
> code without too much horror.

Sure,  but I thought the direction we're going in is to use you wrapper
around the Xen binary.  If that's the case then I don't see much further
use for my code.  


-- 
Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part