On Thu, Jul 24, 2008 at 01:32:37PM +0300, Pasi K?rkk?inen wrote: > On Mon, Jul 21, 2008 at 05:15:41PM +0100, Mark McLoughlin wrote: > > On Mon, 2008-07-21 at 14:13 +0100, Mark McLoughlin wrote: > > > On Fri, 2008-07-18 at 19:10 +0100, Daniel P. Berrange wrote: > > > > On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote: > > > > > Hi, > > > > > Just a heads up that I'm pushing a new 2.6.27 based kernel-xen to > > > > > rawhide. This includes Jeremy Fitzhardinge's xen-64bit tree[1] in place > > > > > of Eduardo's xen-pvops-64.git tree. > > > > > > > > > > Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 > > > > > already and the other half is queued up, hopefully to be included before > > > > > the merge window ends. If we can get that stuff some testing, perhaps it > > > > > might help the cause of getting it merged. > > > > > > > > > > This is all irrelevant if the build fails, of course :-) > > > > > > > > Seems to have succeeded, so how about putting it into the real kernel > > > > RPM directly, and finally kill kernel-xen as an RPM :-) > > > > > > Yes, I'd very much like to make that happen soon. > > > > > > There are two considerations, though: > > > > > > 1) The second half of the xen x86_64 DomU work has not yet been > > > merged upstream. It's a fairly big patch: > > > > > > 49 files changed, 2344 insertions(+), 913 deletions(-) > > > > > > so, if it doesn't get merged, > > > > Sweet, Ingo has just pushed it up to Linus: > > > > http://lkml.org/lkml/2008/7/21/201 > > > > That's really nice progress with upstream merging.. > > I still think it might be a good idea to keep separate kernel-xen until > upstream has "all" the needed features.. > > Like said, adding dom0 patches should be easier to separate rpm? Possibly - that's TDB when we have working Dom0 patches again. The Dom0 patches will have to work against latest LKML tree, so it might turn out to be easy to do against the main kernel RPM. It really depends how unstable/invasive Dom0 bits are. This is a decision that is independant of the guest stuff though. In terms of guest support, we absolutely want 1 kernel for F10. A core point of paravirt_ops is that a single kernel binary can boot and auto detect the hypervisor its running on. This means we can get rid of the separate vmlinuz/initrd in the install trees, get rid of anaconda logic to install a different kernel in Xen guests, and lots of other cleanup. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Fedora-xen mailing list Fedora-xen@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-xen
