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
> 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.
Xen-devel mailing list