From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Xen 4.4 development update: RC0 imminent Date: Thu, 5 Dec 2013 17:53:21 +0000 Message-ID: <52A0BD91.9060704@eu.citrix.com> References: <20131205163425.GA27631@zion.uk.xensource.com> <52A0AC3F.2010605@eu.citrix.com> <20131205164841.GB27631@zion.uk.xensource.com> <1386262760.20047.130.camel@kazak.uk.xensource.com> <20131205170652.GA29387@zion.uk.xensource.com> <1386263815.20047.137.camel@kazak.uk.xensource.com> <20131205173425.GB29387@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Vod7F-0003oJ-Ed for xen-devel@lists.xenproject.org; Thu, 05 Dec 2013 17:53:33 +0000 In-Reply-To: <20131205173425.GB29387@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu , Ian Campbell Cc: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= , =?UTF-8?B?Um9nZXIgUGF1IE1vbm4=?= =?UTF-8?B?w6k=?= , Fabio Fantoni , David Vrabel , xen-devel List-Id: xen-devel@lists.xenproject.org On 12/05/2013 05:34 PM, Wei Liu wrote: > On Thu, Dec 05, 2013 at 05:16:55PM +0000, Ian Campbell wrote: > [...] >>>>> I pinged maintainer this morning, let's see his response later. He's in >>>>> GMT -8 timezone. >>>>> >>>>> If we cannot get it merged within next week I would rather take it off >>>>> our list. >>>> IIRC the Xen side patches were pretty small and straight forward and the >>>> only issue was agreeing the ABI for the struct passed from hvmloader to >>>> ovmf. >>>> >>> Yes, that's the main missing bit. However the interface has been acked >>> on OVMF side, does that mean it is safe to go in now? >> I think so long as the risk that it might change is small we could take >> it. The danger would be that we take it and release it and then someone >> changes their mind or whatever. If they just spotted an issue then we'll >> have to live with it -- just like we would if we committed to both ovmf >> and Xen right now. >> >> There's also an inherent danger in taking something into Xen without the >> 3rd party code which exercises it. >> >> But the advantage is that when OVMF is updated it will be possible to >> use it with Xen. >> >> On the other hand if you need to build an OVMF yourself a few patches to >> hvmloader are probably not a big deal either. I think for the common user, applying patches is a much higher barrier than just downloading a repo. >> >> OK, so I'm clearly in two minds about this ;-) >> >> George -- what do you think? >> > My two cents would be let's see if we can upstream OVMF side patches in > time (it looks quite close now but I cannot say for sure, it's not > controlled by us ;-)), then release it in 4.4 and mark this feature as > experimental. Otherwise there's no need to merge Xen side patches. In time for what? Like I said, I think downloading a repo / tarball and building it is much lower than applying patches and then building. And changing editing the one file in the Xen tree that has the commit hash is easier yet. So I think there's an advantage to checking them in even if OVMF isn't upstream by the time we release. And since OVMF is broken now anyway, we can't really break it; so there's little risk. :-) -George