On 7/22/07, Tim Dijkstra <[EMAIL PROTECTED]> wrote: > On Sun, 22 Jul 2007 07:46:40 +0300 > "Alon Bar-Lev" <[EMAIL PROTECTED]> wrote: > > > On 7/21/07, Tim Dijkstra <[EMAIL PROTECTED]> wrote: > > > No. The vbetool code is linked in. It doesn't run as regular processes. > > > At the time we do those hacks, we are the only not-frozen part of > > > userspace. > > > This is what makes it different from running it from a bunch of scripts. > > > > Are you sure? > > Can you please refer me to the relevant lines in the code? > > Look at suspend.c > > At 1448 we run some hacks before the suspend. A few lines later we call > suspend_system, in that function at 761 we freeze userspace. Then at > line 807 we suspend to ram. If that call returns we're back from > suspend. At 812 we call some more hacks with userspace still frozen, > only after that we jump to Unfreeze. > > 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. Alon. ------------------------------------------------------------------------- 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
