On Tue, Mar 15, 2011 at 8:12 AM, Ian Campbell
<Ian.Campbell@xxxxxxxxxxxxx> wrote:
> On Fri, 2011-03-11 at 14:21 +0000, Konrad Rzeszutek Wilk wrote:
>> On Fri, Mar 11, 2011 at 09:11:31AM +0000, Ian Campbell wrote:
>> > On Thu, 2011-03-10 at 19:29 +0000, Konrad Rzeszutek Wilk wrote:
>> > > Probably over the weekend Linus is going to open the merge window.
>> > >
>> > > This merge window is much more complicated than the previous
>> > > one b/c we got a lot of good stuff.
>> > >
>> > > For my sanity and book-keeping I was thinking to email Linus
>> > > five git pull requests:
>> > [...]
>> > > .. and then during the next week of the two weeks merge window:
>> > [...]
>> > > In this order or so.
>> >
>> > Seems sane. I'm going to rebase my dev tree onto all these now (I think
>> > I've got most of it already)
>>
>> OK. #linux-next is you place then.
>> >
>> > > In other trees by other maintainers we have:
>> > [...]
>> > > git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git has
>> > > xen suspend cleanups
>> > > PVonHVM improvements - makes spinlocks be PV aware, balloon in HVM
>> >
>> > Are Shriram's suspend/checkpoint patches in the pipeline somewhere?
>>
>> <head smack> I knew I forgot something.
>>
>> The last I heard he was battling PVonHVM shutdown issues during his
>> testing of his patches.
>>
>> Shririam?
>
> He posted a series on Saturday, rebased onto Stefano's PVHVM tree + the
> PM tree, it looked sane to me.
>
> I think his patch 1/5 (the one from Kazuhiro Suzuki) could go in any
> time since it has no dependency on either the PVHVM or PM trees.
>
> It also looks to me like patch 4/5 ("PM: Add visible
> HIBERNATION_INTERFACE and hide HIBERNATION") could go upstream via the
> PM tree whenever Rafael likes, since it doesn't depend on any of the
> others. That just leaves 2/5, 3/5 and 5/5 to be pushed through once
I wish it was that easy. Rafael's tree carries a commit that is
missing from both
Konrad's and Stefano's tree.
"PM: Make CONFIG_PM depend on (CONFIG_PM_SLEEP || CONFIG_PM_RUNTIME)"
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -38,7 +38,7 @@ config XEN_MAX_DOMAIN_MEMORY
config XEN_SAVE_RESTORE
bool
- depends on XEN && PM
+ depends on XEN
default y
config XEN_DEBUG_FS
5/5 is based on this patch and that is the reason I had to create a
hybrid tree and base
my patches on it. If this conflict can be easily resolved by whoever
is doing the
merging, then I can resend the 5/5 alone based on stefano's tree and
Ian's idea of
pushing 2,3,5/5 through xen tree would work.
> everything else has settled down.
>
This "everything else has settled down" phrase has been causing lot of
delays :P.
I asked Konrad to pull my git branch, hoping that his test setup(and
his kernel config) would
not face the same issue mine (PVonHVM not shutting down).
The puzzling part is, the same patch series worked neatly during rc4
(Ian's tree) - the first time I
submitted my patches.
shriram
> Ian.
>
>>
>> >
>> > > The things that are not going in 2.6.39 are:
>> > >
>> > > devel/xen-pciback-0.4.driver [xen-pciback]
>> >
>> > Targeting 2.6.40?
>>
>> Yes.
>> >
>> > > devel/xen-blkback-v1 [xen-blkback]
>> >
>> > 2.6.40 again?
>>
>> Yeah, I think by that time any issues/failures would show up and I
>> can fix them.
>> >
>> > > git://xenbits.xen.org/people/ianc/linux-2.6
>> > > upstream/dom0/backend/netback
>> > > [xen-netback - well, it could if the network maintainers are
>> > > comfortable
>> > > with the driver, but I think it is still going through the review]
>> >
>> > I've got another round of (minor) review feedback to address, I'm still
>> > a little bit hopeful for a 2.6.39 merge.
>> >
>> > Either way this will go through the net tree not us.
>>
>> <nods>
>> >
>> > Ian.
>> >
>> >
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@xxxxxxxxxxxxxxxxxxx
>> > http://lists.xensource.com/xen-devel
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home