From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Stodden Subject: Re: Merging xen/dom0/backend/blktap2 .. Date: Thu, 10 Mar 2011 13:57:53 -0800 Message-ID: <1299794273.14978.433.camel@agari.van.xensource.com> References: <1299728032.6740.154.camel@agari.van.xensource.com> <1299745902.17339.712.camel@zakaz.uk.xensource.com> <1299753587.3476.441.camel@ramone.fritz.box> <20110310182435.GB7729@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110310182435.GB7729@dumpdata.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: Konrad Rzeszutek Wilk Cc: Ian Campbell , Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Thu, 2011-03-10 at 13:24 -0500, Konrad Rzeszutek Wilk wrote: > On Thu, Mar 10, 2011 at 02:39:47AM -0800, Daniel Stodden wrote: > > On Thu, 2011-03-10 at 03:31 -0500, Ian Campbell wrote: > > > On Thu, 2011-03-10 at 03:33 +0000, Daniel Stodden wrote: > > > > is an overall pita and I've had the pleasure several times now. > > > > > > Merging it into what? xen/stable-2.6.32.x or some newer upstream version > > > based tree? > > > > Newer upstream. Otherwise I wouldn't bother. It's certainly not a common > > operation, I was just suprised how much garbage is involved. > > There is another party that is interested in doing this too, so it might > be a good idea to compare ideas. Let me ping them to see where they are. > > But putting aside the blktap2 driver - what about that ugly #ifdef CONFIG_XEN > piece of code that went in the generic code. Is that gone? ?? > I would think that the first path would be to post patches that introduce > the required infrastructure. You mean for blktap? There isn't much infrastructure left, except a popular zap_page_range export because it doesn't tear down VMAs, just ptes, to complete requests. I usually try not to not lose history, so just folding that branch (I guess the drivers/block transition is an obvious start point) would not be my preferred solution. But if people prefer that, that's certainly easy to produce. > For that thought you might want to wait when > the merge window opens and Linus starts pulling Stefano's and my tree. At that point > a lot of the infrastructure backends should be in. Or if you like, you can > take a merge of my #linux-next and Stefano's #linux-next and use that as a base. > > I've also up-ported blkback to 2.6.38 - look in devel/xen-blkback-v1 to > see what I needed to do use the override mechanism. I found these commits all picked from your devel/next-2.6.38 tree, so I'm presently still sticking to that. Yup, going to check out the override stuff too. Thanks, Daniel