Re: [Xen-devel] Re: [PATCH] pvops: Make suspend work when CONFIG_SUSPEND=n

[Shriram Rajagopalan <rshriram@xxxxxxxxx>]

On Fri, Mar 4, 2011 at 7:56 AM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
> On Fri, Mar 04, 2011 at 07:42:00AM -0800, Shriram Rajagopalan wrote:
>> On Fri, Mar 4, 2011 at 3:52 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> 
>> wrote:
>> > On Fri, 2011-03-04 at 11:45 +0000, Frank Pan wrote:
>> >> > AFAIK the conclusion is that an approach which ensures both
>> >> > XEN_SAVE_RESTORE and SUSPEND (actually HIBERNATE after the above
>> >> > discussion) are enable when necessary (by making the former depend on
>> >> > the later) is what is going to be taken.
>> >>
>> >> That's good. How long will it be committed on pvops trees?
>> >
>> > I don't know. Stefano, Rafael and Shriram are taking care of it AFAIK.
>> >
>> Well, from my side, I am waiting on Stefano & Rafael. The discussion seemed
>> to have ended with "lets wait for the code to settle", though there seemed 
>> to be
>> no consensus regarding the need to enable HIBERNATE for XEN_SAVE_RESTORE
>> to work.
>>  Someone suggested creating a new user visible hibernate symbol that would
>> solve this issue and make the main hibernate logic depend on this symbol 
>> rather
>> than the HIBERNATE symbol. I could certainly spin up a patch for that but 
>> nobody
>> seemed to have reached a conclusion.
>
> Please do. I was under the understanding that we were waiting for a 
> victi^H^H^Hvolunteer
> to implement that.
>
> That was the only thing gatting your patchset going in.
>
>

I certainly would have long time ago but for this comment in the thread
"xen: fix XEN_SAVE_RESTORE Kconfig dependencies"

Rafael:
 I think we can introduce CONFIG_HIBERNATE_INTERFACE that will be user-visible
option instead of CONFIG_HIBERNATION and will select the latter.  Then,
CONFIG_XEN_SAVE_RESTORE will also be able to select CONFIG_HIBERNATION without
building the hibernate interface in, which will prevent user space from being
confused, but that will cause too much code to be built anyway.

If by "too much code to be built", he meant the increase in kernel
image size, then its not much of a deal :P.
But if he meant, "too much code rework", then it is an issue.

But IMO, the CONFIG_HIBERNATE_INTERFACE needs to go in,
only in the main hibernation initiator logic, as we still need the
CONFIG_HIBERNATE
pieces of every driver anyway (their freeze/thaw routines).

shriram

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