[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] domain builder for ReactOS
On Fri, Jun 03, 2005 at 12:51:09AM +0200, Ge van Geldorp wrote: > > From: Christian Limpach > > > > Why do you think that you need a different builder? > > Especially since you're going to use a bootloader anyway, > > your actual kernel image file can be of whatever format you > > like... If your main/only struggle is with the ELF format, > > then please consider adding support for additional loaders in > > the existing builder. > > Yes, the reason for the different builder is that our bootloader is not in > ELF format. Well, your webpage says that right now you're building your loader as an ELF image and I guess use the linux builder? Can't you stick with that? Even if it's inconvenient to only being able to build the loader on Linux, how often does the loader need to be rebuilt? > I'm not sure the linux ELF loader and my loader are going to > have much code in common, which is why I opted for a different builder. The elf loading functions in xc_linux_build make up less than half of the file -- ideally you should be able to use the setup_guest and xc_linux_build functions without too many changes. I'd suggest that you move the elf loading functions into a separate file (xc_load_elf.c) and put your load functions in a different file. You'll also need to add a probe function to identify the type of the image, which could then return a pointer to a struct with function pointers to parseelfimage/loadelfimage in the elf case and then call these through the pointers. > However, I don't see major problems adding the code to the Linux builder, so > if that's what you prefer, that's how I'll do it. The other question is whether it makes much sense to add a loader/builder before there's a kernel? christian _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |