On Thu, Jul 24, 2008 at 11:37:05AM +0100, Daniel P. Berrange wrote: > 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. > Ok. > 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. > That makes sense. Thanks. -- Pasi -- Fedora-xen mailing list Fedora-xen@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-xen
