From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Xen 4.3 development update, and stock-taking Date: Fri, 18 Jan 2013 10:21:47 -0500 Message-ID: <20130118152147.GB9973@phenom.dumpdata.com> References: <50F7CBA4.1070408@citrix.com> <50F7DEED.1050401@eu.citrix.com> <50F91AF6.4020400@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <50F91AF6.4020400@citrix.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: Roger Pau =?iso-8859-1?Q?Monn=E9?= Cc: George Dunlap , Ian Jackson , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Fri, Jan 18, 2013 at 10:50:46AM +0100, Roger Pau Monn=E9 wrote: > On 17/01/13 12:22, George Dunlap wrote: > > On 17/01/13 10:00, Roger Pau Monne wrote: > >> On 16/01/13 18:55, George Dunlap wrote: > >>> * Persistent grants for blk (external) > >>> owner: roger.pau@citrix > >>> status: Initial implementation posted > >>> prognosis: ? > >> Done, Linux implementation scheduled for 3.8, and Qemu side is also do= ne > >> and being upstreamed right now. > > = > > OK, so I'll mark the Linux component as "done", and the qemu component = > > as "Good". > > = > >>> * Persistent grants for net > >>> owner: annie.li@citrix > >>> status: Initial implementation posted > >>> prognosis: ? > >>> > >>> * Multi-page blk rings (external) > >>> - blkback in kernel (konrad@oracle, ?@intel) > >>> - qemu blkback > >>> status: Not started. > >>> prognosis: UNKNOWN > >> I will be taking on this project, following Intel, FreeBSD and Konrad > >> suggestions. Since I'm just starting now, I will mark it as "Fair". > > = > > OK, thanks for the info. Out of curiosity, if someone were to consider = > > this a blocker, would having someone else working on it speed things up= , = > > do you think? Or is it development probably "non-parallelizable"? :-) > = > Let's wait until we have a clear roadmap about how are we going to > handle it. This is not related to Xen itself, so I wouldn't see it as a > blocker, most of the work will be done in the Linux kernel, and the only > hypervisor part of this might be changes to the block protocol (blkif.h) > and the ring (ring.h) protocol. Did you have a chance to look at the issues I enumerated with the block protocol? Perhaps we should continue the discussion on the "clear roadmap" on that thread?