Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Shriram Rajagopalan <rshriram@xxxxxxxxx>]

On 2011-03-16, at 2:40 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:

> On Tue, 2011-03-15 at 22:16 +0000, Konrad Rzeszutek Wilk wrote:
> 
>>> If Rafael is happy with that plan then fine, but I didn't see him ack it
>>> in that thread (AFAICT he only acked the concept of what the patch would
>>> do). Either way someone still needs to follow up with him to get an Ack
>>> on the 4/5 patch since it is to the PM core, if he's subsequently also
>> 
>> Yup. Please do ping him for his ACK. He needs to OK
>> 
>>      PM: Add visible HIBERNATION_INTERFACE and hide HIBERNATION
>> 
>> 
>> patch. 
> 
> So I was chewing on this last night and I don't see why 2/5 "xen: use
> freeze/restore/thaw PM events for suspend/resume/chkpt" needs to be
> blocked by these core Kconfig changes.
> 
> The patch makes the Kconfig breakage different but it doesn't make it
> any worse -- it just exchanges a false(/implicit?) dependency on
> CONFIG_PM_SLEEP for one on CONFIG_HIBERNATE instead.
> 
> I suspect the change from CONFIG_PM_SLEEP->CONFIG_XEN_SAVE_RESTORE in
> 2/5 could be done as CONFIG_PM_SLEEP->CONFIG_HIBERNATE for now and only
> switch to CONFIG_XEN_SAVE_RESTORE when the Kconfig stuff is sorted in
> 5/5.
> 
Why the change? The patch 2/5 currently currently makes the code block depend 
on the configuration that it actually corresponds to.
> So IMHO:
> 
> 1/5 xen: xenbus PM events support
> 
>        Can go in now via a Xen tree. No brainer.
> 
> 2/5 xen: use freeze/restore/thaw PM events for suspend/resume/chkpt
> 
>        Can go in now via a Xen tree. Contains a real bugfix and doesn't
>        make the Kconfig situation any worse. Should probably have
>        s/CONFIG_XEN_SAVE_RESTORE/CONFIG_HIBERNATION/ done to it for the
>        time being (see 5/5).
> 
> 3/5 PM: pm.h - Add comments about Xen save/restore/chkpt use case
> 
>        Can go in via the PM tree at leisure.
> 
> 4/5 PM: Add visible HIBERNATION_INTERFACE and hide HIBERNATION
> 
>        Should go via PM tree once Rafael is happy with it.
> 
> 5/5 xen: fix XEN_SAVE_RESTORE Kconfig dependencies
> 
>        Needs to follow both 2/5 and 4/5.
Nope. I think it still can go in as is. All it does is to select HIBERNATION 
(not clean, unless 4 exists but not buggy either). See below for reasoning.
> Can most likely go via either
>        tree with cross-maintainer agreement. Probably best via PM tree
>        due to dependency on 4/5 since 2/5 can go in independently
>        before then.
> 
>        Should incorporate the bit of 2/5 undone via the
>        s/CONFIG_XEN_SAVE_RESTORE/CONFIG_HIBERNATION/
> 
> Basically 1/5..2/5 and 3/5..5/5 are two separate series and 1/5..2/5 can
> go in now...
> 
> Worst case is 2/5 makes it into 2.6.39 and 5/5 doesn't, in which case we
> just need to remember to ask "Have you enabled CONFIG_HIBERNATE?"
> instead of "Have you enabled CONFIG_PM_SLEEP?". In reality most kernel
> configs are distro like and probably have both anyway.
> 
Exactly. Which means the current 5/5's (select HIBERNATION) would be a dud in 
most distro kernels. For those who configure by hand, in case "select 
HIBERNATION" fails, xen-save-restore would be disabled and things won't work.
 I agree that this is not aesthetic but your alternative would cause "pain" :).
 Common to both alternatives is the "feature" that sys/power/disk would be 
visible to the user and there would be folks attempting to "hibernate their 
vms". This would be the worst case, where we could say "it doest work".
> Also the suspend changes which are already upstream make the error
> reporting and toolstack behaviour when this happens better than
> previously as well.
> 
> Ian.
> 
We could avoid some more extra pain to users who use custom kernel configs. If 
they had disabled SWAP, then "select HIBERNATION" won't work. Could possibly 
happen in some distro kernel too (not sure which ones). 
 A solution for this would be to "select SWAP" too, under XEN_SAVE_RESTORE. 
This was in an earlier version of the patch series.
So when Rafael releases his own version of refactoring patch 4/5 (as he said he 
would do in a "while"), we could simply remove the "select SWAP" line from 
xen-save-restore kconfig.

So to summarize:
 1,2,5 could either go "as-is" now into the xen tree or with a little tweak to 
5/5 (adding the select SWAP part)

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