Re: Q: Clarification about extra option ..Re: Re: [PATCH] pvops: Make suspend work when CONFIG_SUSPEND=n

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Sunday, March 06, 2011, Shriram Rajagopalan wrote:
> On Fri, Mar 4, 2011 at 12:07 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Friday, March 04, 2011, Shriram Rajagopalan wrote:
> >> On Fri, Mar 4, 2011 at 10:26 AM, Konrad Rzeszutek Wilk
> >> <konrad.wilk@oracle.com> wrote:
> >> > .. snip..
> >> >> >>  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.
> >> >
> >> > The idea here is that the /sys/power/state won't be exposed with the "disk"
> >> > option.
> >> >
> >> >>
> >> >> 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).
> >> >
> >> > Right. The idea here is to seperate the sysfs interface to be behind
> >> > another config option. So you can still enable the hibernate kernel code
> >> > but without exposing it to the userland.
> >> >
> >> > Rafael,
> >> >
> >> > That is the general idea, right?
> >> >
> >> >
> >>
> >> I was thinking along the lines of
> >> config HIBERNATION
> >>  def_bool n
> >>
> >> config HIBERNATION_INTERFACE
> >>  select HIBERNATE
> >
> > select HIBERNATION
> >
> >> config XEN_SAVE_RESTORE
> >>  select HIBERNATION
> >>
> >> in kernel/power/Makefile
> >> obj-$(CONFIG_HIBERNATION_INTERFACE)  += hibernate.o snapshot.o swap.o \
> >>
> >>   user.o block_io.o
> >>
> >> Will this be sufficient to prevent unnecessary code from being built?
> >
> > Not all of it, but the majority.
> >
> >> Or, is this oversimplified file exclusion totally wrong and I have to
> >> dig deeper?
> >
> > That can be done in the future over time.
> >
> >> From a cursory glance, these files seem to be dealing solely with SWSUSP which
> >> roughly does the following:
> >>  1. freezing devices (using pm_op functions in main.c)
> >>  2. saving memory to swap
> >>  3. thawing on resume (using pm_op functions in main.c)
> >>
> >> XEN_SAVE_RESTORE only needs steps 1 & 3.
> >
> > That's correct.
> >
> > Thanks,
> > Rafael
> >
> >
> 
> Is it okay if I send out both the HIBERNATION_INTERFACE patch and
> the XEN_SAVE_RESTORE kconfig fixes against Rafael's tree?
> 
> Rafael's tree on git.kernel.org and Stefano tree on
> http://xenbits.xen.org/gitweb/ are out of sync (on linux-next branch,
> 2.6.38-rc6).
> I am referring to files arch/x86/xen/Kconfig and kernel/power/Kconfig that
> would be touched by these two patches.
> 
> Rafael's commit 5b56bff0f50bc1ed643c2ae85e803d17fc0a110e
> "PM: Make CONFIG_PM depend on (CONFIG_PM_SLEEP || CONFIG_PM_RUNTIME)"
> touches both these files and this commit is not present in stefano's tree.
> 
> The only issue is that I cannot completely "test" these two patches
> against Rafael's tree
>  - I have verified that the kernel config file generated is as expected.
>  - I cannot verify any other xen save/restore functionality as my xen
>    suspend freeze-thaw patches dont apply cleanly on Rafael's tree
>   (it does not have xen suspend refactoring patches
>   ceb180294790c8a6a437533488616f6b591b49d0, that my patches depend on.
>   They are present only in Stefano's tree).

In that case, I'm afraid, it's better to wait until both trees are merged
and push your patches at that time.

Thanks,
Rafael