| There really needs to be some leadership resolve on these issues -
we
| can't have the kernel hacking going on with no clear over-all
| distribution guidance. I've read this thread with trepidation
lately.
Welcome to the FOSS world.
Duh, I've been in the FOSS world since the 80's. This ain't news.
| The whole issue of the state of devices during suspend/resume *is* a
| kernel issue, and it *is* a user space issue. The kernel needs to
do
| what its told to do by devices, and the state of these devices
What?
Suspend is a run-level. Resume is a run-level. Yes, even a power-
down of a component is a matter of run-level state change.
The state of devices and services during, while, and after these
changes in run-level, ought to be governed by init scripts. If I
change run-level to 'suspending', then the init scripts surrounding
that run-level state change can check the status of all devices, write
to disk, then .. when the 'resume' run-level scripts are run, the
state of the devices can be determined, and set back to what they were
before the run-level change.
I work on safety-critical systems for THALES. We put the system in
the *same* state it was in before the run-level change, because we are
an OS. The Applications groups need stability around this issue; the
same is true for us OpenMoko developers. If I've written an app, I
want to know if the screen is on, if the CPU is in lower-power mode,
etc. My apps depend on knowing these details; it is up to the kernel
to provide the answer to this question.
;
--
Jay Vaughan
