WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] multiboot-like module support

Ian Campbell, le Wed 09 Dec 2009 14:29:35 +0000, a écrit :
> On Wed, 2009-12-09 at 14:01 +0000, Samuel Thibault wrote:
> > + * A multiboot module is a package containing modules very similar to
> > a
> > + * multiboot module array. The only differences are: 
> 
> I don't really know the multiboot layout but is there a reason not to
> use it as is rather than defining a new version?

It'd make the builder more tricky, as multiboot uses absolute
physical addresses.  That'd mean extending libxc in order to take
the list of modules itself and build the table very late, during
xc_dom_build_image(), when the target virtual address is known, while
by using relative offsets, there is no need to, it's self-contained.
Relative offsets also permit to build a package even before submitting
it to xm create (that's how I'm using it atm actually).
I'm not against it, it's just that it is much less simple. One good
thing however is that then the code building the table would be in
libxc, shared by pv-grub and xend.

The other difference is how to know the number of modules.  In the
multiboot standard, it's simply set in the boot_info structure.  That
could be added to the start_info structure for instance.

> I would imagine that using the standard layout could potentially lead to
> less Xen specific code on the guest side.

Well, yes, I'd just answer that there aren't so many multiboot
implementations anyway :)

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel