Re: [Xen-devel] Merging xen/dom0/backend/blktap2 ..

[Daniel Stodden <daniel.stodden@xxxxxxxxxx>]

On Tue, 2011-03-15 at 15:53 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 15, 2011 at 05:44:06AM -0700, Daniel Stodden wrote:
> > On Thu, 2011-03-10 at 05:39 -0500, 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.
> > 
> > After looking at the series, I think reverting on that topic branch
> > might just risk more issues in trees which already pulled the current
> > branch, and gathering the right diffs from Jeremy's tree to avoid that
> > would probably take me longer than it's worth. More time than I can
> > afford.
> > 
> > Since Konrad already seems to do the same with blkback, I'd like to
> > propose a reset.
> > 
> > Please check out one of the following trees at
> > http://xenbits.xensource.com/gitweb/?p=people/dstodden/linux.git;a=summary
> > git://xenbits.xensource.com/people/dstodden/linux.git
> > 
> > blktap/next-2.6.38
> > blktap/next-2.6.37
> > blktap/next-2.6.36
> > blktap/next-2.6.33
> > blktap/next-2.6.32
> > 
> > I'd redo xen/dom0/backend/blktap2 and repost the diffs sent around last
> > week. I wouldn't mind keeping that branch in sync too, assuming it
> > helps.
> > 
> > Trees above start at v2.6.32, with the transition to
> > drivers/block/blktap, and moving on with Linus' tree from there on.
> > Versions chosen above are where forward ports were necessary,
> > respectively. Only fuzz left is mm/memory.c (export zap_page_range for
> > modules).
> 
> Can you make a different branch (or just send me the git commit)
> for the one that touches mm/memory.c?

That's the initial one: 7ccd87f. You could strip that but it's not going
to build as a module before that ref is gone. It might go at some point.

> > 
> > Does this sound acceptable?
> 
> I looked briefly at blktap/next-2.6.38 and it looks like an ongoing
> merge tree. Can you make a tree that is based off 2.6.38 (or some
> branch of my 'stable/' ones). Basically trying to have something that is
> easy to merge and is self-containted within one branch.

It is rooted on 2.6.32 and incrementally moves on up to currently
v2.6.38, no stray diffs except the forward porting where needed. There's
at least one conflict resolution in Kconfig around 36 or 37, iirc. Any
later kernel will look more or less the same.

$ git list xenbits/blktap/next-2.6.38 ^v2.6.38
eb8040c Merge commit 'v2.6.38' into blktap/next-2.6.38
bf926e6 blktap: Forward port to 2.6.37
9f65e90 Merge commit 'v2.6.37' into blktap/next-2.6.37
7ef4e35 blktap: Forward port to 2.6.36
a55f064 Merge commit 'v2.6.36' into blktap/next-2.6.36
994a546 blktap: Add discard queue limits.
ea2d7e7 Merge blktap into blktap/next-2.6.33
e37d737 blktap: Add BLKTAP_OP_TRIM command option.
42276df blktap: Add BLKTAP_OP_FLUSH command option.
5d10876 blktap: Add physical sector device info.
8169b25 blktap: Drop the ring message timestamp.
34574a8 blktap: Support non-R/W requests
a765257 blktap: Fix reference to freed struct request.
7ccd87f blktap: Blktap userspace devices.

You could rebase it on v2.6.38 if you want to reproduce the merging and
mangle commits, although I'm not sure why. For the foreseeable future,
I'd like to keep 2.6.32 and anything later going, so that repo will get
incoming stuff at 2.6.32 and, where possible, I'd expect the greater
kernels to typically just fast-forward from where they are now.

If you want topic branches: I'm not planning to do those. Mainly because
it's a bad idea. If that entire thing would be about to go upstream with
limited time to land that might a different thing, but it's clearly not
there in its present state.

That acceptable?

Daniel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel