On Sunday, March 06, 2011, Shriram Rajagopalan wrote:
> On Fri, Mar 4, 2011 at 12:07 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
> > On Friday, March 04, 2011, Shriram Rajagopalan wrote:
> >> On Fri, Mar 4, 2011 at 10:26 AM, Konrad Rzeszutek Wilk
> >> <konrad.wilk@xxxxxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home