From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Ostrowski Subject: Re: RFC/Patch: Support for other bootloaders Date: Wed, 23 Mar 2005 11:44:54 -0500 Message-ID: <1111596294.4293.265.camel@brick.watson.ibm.com> References: <20050323162357.GC16918@cray.cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-I1oB8Bzjo9WZ95mdC3VO" In-Reply-To: <20050323162357.GC16918@cray.cl.cam.ac.uk> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Tim Deegan Cc: Ian Pratt , Keir Fraser , xen-devel@lists.sourceforge.net, ian.pratt@cl.cam.ac.uk List-Id: xen-devel@lists.xenproject.org --=-I1oB8Bzjo9WZ95mdC3VO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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. >=20 > 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 >=20 > $ cat vmlinux-xen0 initrd-xen0 >pseudo-initrd >=20 > boot: xen pseudo-initrd. >=20 > and then have Xen root around in the ELF headers to see where the break > is. >=20 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.) >=20 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. =20 --=20 Michal Ostrowski --=-I1oB8Bzjo9WZ95mdC3VO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCQZ0GDMDCqU5zPMARAjWwAJ4/MMJXY8cgSIYtwLeJZrPKWha0VACfTkkX Rzap/h9dS2nYsqgdijEPWIc= =gglK -----END PGP SIGNATURE----- --=-I1oB8Bzjo9WZ95mdC3VO-- ------------------------------------------------------- This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click