From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH 00/17] Netchannel2 for a modern git kernel Date: Mon, 05 Oct 2009 14:22:18 -0700 Message-ID: <4ACA638A.5060209@goop.org> References: <4AC92B44.5020208@goop.org> <20091005092937.GA1036@weybridge.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20091005092937.GA1036@weybridge.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Steven Smith Cc: Steven Smith , "keir.fraser@citrix.com" , "xen-devel@lists.xensource.com" , "joserenato.santos@hp.com" List-Id: xen-devel@lists.xenproject.org On 10/05/09 02:29, Steven Smith wrote: >>> This is a forward port of the NC2 patches I posted against so that >>> they apply to Jeremy's git tree, rather than the XCI patchqueue. It's >>> identical in most important respects, except that I've not included >>> any of the VMQ patches. >>> >> Do you have a git tree I can pull these from? I have >> git://xenbits.xensource.com/people/ssmith/netchannel2-pvops.git in my >> list of repos, but you don't seem to have updated it. >> > Oops, sorry about that. It should all be in now, in the nc2/master > branch. > > (Although you may want to wait until the discussion about the new > grant table interface is sorted out before pulling.) > Thanks. I've pulled it anyway, but not yet merged it into anything yet. What dependencies does it have on the rest of the xen changes? In general I like to avoid basing branches on xen/master, because it makes them fairly brittle to rebase or otherwise rearrange. Ideally I like to base each topic branch on a mainline kernel version (like v2.6.31), or if there are too many dependencies on other Xen topic branches, the most specific one that covers the dependencies (xen/core, xen/dom0/core, for example). Also, does this include both front and backend parts together? I think it would be easier to deal with if you could split it into separate common, frontend and backend branches. Or maybe that would be too fiddly... J