From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jacob Gorm Hansen Subject: Re: [PATCH] domain builder for ReactOS Date: Mon, 06 Jun 2005 11:44:13 -0700 Message-ID: <42A4997D.8090108@diku.dk> References: <200506022353.j52NrW8K032664@mailhost.geldorp.nl> <42A38B49.2020308@diku.dk> <3d8eece20506060149248d2e1@mail.gmail.com> <42A4158A.6070206@diku.dk> <3d8eece20506061133627da9f7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <3d8eece20506061133627da9f7@mail.gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christian.Limpach@cl.cam.ac.uk Cc: xen-devel List-Id: xen-devel@lists.xenproject.org Christian Limpach wrote: > On 6/6/05, Jacob Gorm Hansen wrote: > > The model you suggest requires you to install the kernel such that it > is accessible from within the guest environment. This is not always > desirable nor practical. > [some off-list exchange skipped] > I like the loader + "ramdisk" solution. Can you reuse the code we > have in the builder now to load elf, elf w/ symtab and bin images? > Isn't the development environment for the loader too hostile? I > implemented a similar loader for NetBSD when the linux dom0 loader > didn't support elf yet -- it was quite tedious to relocate stuff in > memory so that the layout would be the same for the loader and the > image it would execute... My code is a port of the loader as per last autumn (I forward-ported my old code to the new Xen), so right now it only loads ELF, I guess I could work in later changes as well. You are right that developing stage2 loaders is harder than writing Linux binaries, though with a serial cable things are not too bad. The worst part is turning over control to the OS itself, because you need a temporary overlap of address spaces, and you would like to free some of the original domain memory, or at least hand it over the OS. Jacob