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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

> > 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.

For upstream we need that as a separate git commit. Otherwise we might
not get MM maintainers Ack-ing the git commit b/c they would have to review
the blktap driver too. Please do split it out in two commits.

> 
> > > 
> > > 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

Ah, ambitious. I tried that with xen-pcifront and had to resort
to making trees for different versions. But this could work for you.

> kernels to typically just fast-forward from where they are now.

The issue is git bisection. The dates on those commits is quite early so
I wonder if somebody did a git bisect whether they would hit those and
end up with compilation issues. Perhaps the first patch should
just introduce the driver, but not touch the Kconfig at all.

And then the last one actually enables the Kconfig. And as you
add updates, you move the patch with Kconfig to be the last one?

> 
> 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.

What is a "bad" about it? What do you want to do when the driver is ready
for upstream? You would have to do this topic branch at some point, wouldn't 
you?
What is a topic branch to you? When I think topic branch I think:
devel/xen-pciback-0.5 for example.

The reason I am asking about this is b/c of my inept git skills. Doing
"git pull daniel/blktap" and just having it fetch patches that are relevant
to blktap makes it soooo much easier to get an idea what is happening. And also
if I need to revert something - but it could be very well me not being
elite with git.

Granted if there are bug fixes for things that aren't in the topic branch
but surface up in a merge branch (example: 2.6.38 + #your tree) I usually just
rebase it on top of 2.6.38 so I can have that patch in and also give that
branch a new name (v3->v4, and so on).

> 
> That acceptable?
> 
> Daniel

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