Proposal: "debug" branch for the kernel
jayv at synth.net
Wed Jul 9 10:56:34 CEST 2008
> | There really needs to be some leadership resolve on these issues -
> | can't have the kernel hacking going on with no clear over-all
> | distribution guidance. I've read this thread with trepidation
> 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
> | what its told to do by devices, and the state of these devices
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.
More information about the openmoko-kernel