On Fri, Mar 4, 2011 at 10:26 AM, Konrad Rzeszutek Wilk
> .. 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"
>> I think we can introduce CONFIG_HIBERNATE_INTERFACE that will be
>> option instead of CONFIG_HIBERNATION and will select the latter. Then,
>> CONFIG_XEN_SAVE_RESTORE will also be able to select CONFIG_HIBERNATION
>> 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"
>> But IMO, the CONFIG_HIBERNATE_INTERFACE needs to go in,
>> only in the main hibernation initiator logic, as we still need the
>> 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.
> That is the general idea, right?
I was thinking along the lines of
obj-$(CONFIG_HIBERNATION_INTERFACE) += hibernate.o snapshot.o swap.o \
Will this be sufficient to prevent unnecessary code from being built?
Or, is this oversimplified file exclusion totally wrong and I have to
>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.
Xen-devel mailing list