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

["Rafael J. Wysocki" <rjw@xxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel