Paravirt-ops next steps

Paravirt-ops next steps

[Zachary Amsden]

So it's gotten a bit confusing to figure out how we should go about 
upstreaming the rest of our patches.  Our patchkit in the paravirt-ops 
tree currently applies to 2.6.19-rc4-mm2, but there are a number of 
conflicts that got resolved when merging into Andi's i386 tree.

What is the best way to sanitize the remaining patches so they smoothly 
integrate into the appropriate trees?  Should we rebase to Andi's tree, 
resync to -rc5-mm1, or just cross our fingers and fix up rejects as they 
occur?

Right now I'm working on getting the timer code for VMI fixed up, and it 
requires several hooks in the timer infrastructure and possibly the APIC 
infrastructure that has been changed a lot recently by Thomas Gleixner's 
patches - I don't see any obvious conflicts, and the new code looks 
better, but it would be comforting to know I am baking changes against 
the right tree.

Zach

Re: Paravirt-ops next steps

[Andrew Morton]

On Thu, 09 Nov 2006 19:27:30 -0800
Zachary Amsden <zach@vmware.com> wrote:

> So it's gotten a bit confusing to figure out how we should go about 
> upstreaming the rest of our patches.  Our patchkit in the paravirt-ops 
> tree currently applies to 2.6.19-rc4-mm2, but there are a number of 
> conflicts that got resolved when merging into Andi's i386 tree.
> 
> What is the best way to sanitize the remaining patches so they smoothly 
> integrate into the appropriate trees?  Should we rebase to Andi's tree, 
> resync to -rc5-mm1, or just cross our fingers and fix up rejects as they 
> occur?
> 
> Right now I'm working on getting the timer code for VMI fixed up, and it 
> requires several hooks in the timer infrastructure and possibly the APIC 
> infrastructure that has been changed a lot recently by Thomas Gleixner's 
> patches - I don't see any obvious conflicts, and the new code looks 
> better, but it would be comforting to know I am baking changes against 
> the right tree.
> 

It'd be better to develop and test this work on top of Thomas's stuff, as
that's what 2.6.20 will doubtless look like.  That means working against
-mm.  Once Thomas's patches are in mainline then the patches will apply to
Andi's tree too and I can send them over to him.

That way, the patch-applying-order equals mainstream-merging-order equals
chronological-writing-order, which is generally a good thing.

Re: Paravirt-ops next steps

[Zachary Amsden]

Andrew Morton wrote:
> It'd be better to develop and test this work on top of Thomas's stuff, as
> that's what 2.6.20 will doubtless look like.  That means working against
> -mm.  Once Thomas's patches are in mainline then the patches will apply to
> Andi's tree too and I can send them over to him.
>
> That way, the patch-applying-order equals mainstream-merging-order equals
> chronological-writing-order, which is generally a good thing.
>   

Sounds sane.  Are Thomas's patches in -rc5-mm1?  If so, we should rebase 
paravirt-ops, although I don't want to lose any paravirt patches that 
you've dropped because they were merged to Andi.  Don't know if that is 
the case, but I did see a bunch of "merged into a subsystem tree" drops 
from -mm related to paravirt.

Thanks,

Zach

Re: Paravirt-ops next steps

[Andrew Morton]

On Thu, 09 Nov 2006 19:48:06 -0800
Zachary Amsden <zach@vmware.com> wrote:

> Andrew Morton wrote:
> > It'd be better to develop and test this work on top of Thomas's stuff, as
> > that's what 2.6.20 will doubtless look like.  That means working against
> > -mm.  Once Thomas's patches are in mainline then the patches will apply to
> > Andi's tree too and I can send them over to him.
> >
> > That way, the patch-applying-order equals mainstream-merging-order equals
> > chronological-writing-order, which is generally a good thing.
> >   
> 
> Sounds sane.  Are Thomas's patches in -rc5-mm1?

Yes.  That patch series was today dropped and remerged, but it won't have
changed much at all.

>  If so, we should rebase 
> paravirt-ops, although I don't want to lose any paravirt patches that 
> you've dropped because they were merged to Andi.

Anything that's in Andi's tree is in -mm too, so when patches are moved
mm->andi->mainline nothing will change from your POV.

>  Don't know if that is 
> the case, but I did see a bunch of "merged into a subsystem tree" drops 
> from -mm related to paravirt.

Some of them went mm->andi, others were folded into others and remain in
-mm, but the net effect is unaltered from your POV.

Re: Paravirt-ops next steps

[Zachary Amsden]

Andrew Morton wrote:
>   
>>  Don't know if that is 
>> the case, but I did see a bunch of "merged into a subsystem tree" drops 
>> from -mm related to paravirt.
>>     
>
> Some of them went mm->andi, others were folded into others and remain in
> -mm, but the net effect is unaltered from your POV.
>   

Most excellent.  :)

Thanks,

Zach