Hi!
> > > 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
We probably want to fix that :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------------------------------------------------------------------
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
