On Fri, Jul 27, 2007 at 05:48:52PM +0300, Alon Bar-Lev wrote: > On 7/27/07, Stefan Seyfried <[EMAIL PROTECTED]> wrote: > > On Sun, Jul 22, 2007 at 10:09:50PM +0300, Alon Bar-Lev wrote: > > > > These s2ram_* funcs in the end call code from vbetool/vbetool.c which > > > > is indeed linked in. But partly I remembered it wrongly. The hacks > > > > _before_ suspend are called with an unfrozen userspace, those after on > > > > a frozen userspace. > > > > > > So these hacks can be removed from suspend code... And moved into the > > > hibernate-script or pm-utils. > > > > No they can't. Because e.g. vbe_save returns a pointer to the contents of > > the VBE buffer which is later used for vbe_restore and thus we don't need a > > temporary file (which, again, might need a working disk, which you cannot > > always assume if you start getting a new machine ready for suspending). > > > > Anyway, i think you are just trolling from here on. > > I don't think so.... > It worked OK until now with hibernate-script and sysfs.
Exactly. So just go ahead and dont use s2ram. Nobody forces you to do so. Or - a second option - go ahead, implement all the stuff that you want in s2ram and create a suspend-ng project. Maybe this is actually what the world needs, you will be hugely successful, and i will gladly accept that i am proven wrong. > You can always assume a working disk or tmpfs during suspend/resume cycle! tmpfs maybe, but disk, no, you cannot. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
