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
> 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.
Xen-devel mailing list