From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: Q: Clarification about extra option ..Re: Re: [PATCH] pvops: Make suspend work when CONFIG_SUSPEND=n Date: Fri, 4 Mar 2011 21:05:48 +0100 Message-ID: <201103042105.49031.rjw@sisk.pl> References: <20110304182602.GA4004@dumpdata.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110304182602.GA4004@dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: Jeremy Fitzhardinge , Stefano Stabellini , Frank Pan , Ian Campbell , "xen-devel@lists.xensource.com" , Shriram Rajagopalan List-Id: xen-devel@lists.xenproject.org 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