On Friday, March 04, 2011, Konrad Rzeszutek Wilk 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?
Right. We can only make the code in kernel/power/snapshot.c depend on
CONFIG_HIBERNATE_INTERFACE and the ioctl interface too.
Thanks,
Rafael
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|