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).
shriram
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home