Bastian Blank, le Tue 15 Dec 2009 20:04:44 +0100, a écrit :
> On Tue, Dec 15, 2009 at 07:32:58PM +0100, Samuel Thibault wrote:
> > Bastian Blank, le Tue 15 Dec 2009 19:02:28 +0100, a écrit :
> > > I would like to have some further packages anyway: pv-grub,
> > I cannot but agree with this one, since we'll need it to nicely boot
> > GNU/Mach-based Xen domUs :)
>
> Why?
Because it permits to load /hurd/ext2fs and /lib/ld.so directly from the
guest itself without having to patch pygrub yet more.
> > > qemu-stubdom.
> > This one will probably be a bit difficult: it's both using the dm fork
> > of qemu, and the cross-compilation stubdom environment.
>
> No, there is no real cross-compilation involved.
Then I don't know what you call building with -nostdinc -isystem etc.
> > > But the build environment for that needs a complete rewrite to be able
> > > to produce acceptable packages. It needs to reuse existing packages.
> > Yes, each time I've thought about it I got a headache :)
>
> The problem is that that the three parts (qemu/grub, newlib/libpci/libz
> and mini-os) are not independant from each other. IMHO in a perfect
> world all this variants could use one mini-os and combining them only
> takes a linker call with a special linker script.
So it would be an extended multilib compilation: x86, x86_64,
minios-x86, minios-x86_64? Mini-os could indeed provide a library to be
linked with and you just need to provide main(). The eventual linkers
of all this would be qemu and grub. There is still the problem of
having to rebuild whenever a library changes since there's no dynamic
sharing, but yes.
> Also qemu-stubdom needs this fs-backend, which runs as root on the dom0,
> just to read the keymaps (they are combined less than 1MiB, so building
> them into the binary should be no problem).
It also needs it for files non backed by a blktap, e.g. cdroms iirc.
Samuel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home