Proposal: "debug" branch for the kernel

Jay Vaughan jayv at
Wed Jul 9 10:56:34 CEST 2008

> | 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

More information about the openmoko-kernel mailing list