Proposal: "debug" branch for the kernel

[Carsten Haitzler (The Rasterman)]

On Wed, 9 Jul 2008 10:56:34 +0200 Jay Vaughan <jayv at synth.net> babbled:

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

i really dont think we want/need a run-level system here. other than it being
slow and making our suspend.resume cycles slower, suspend/resume is TRANSPARENT
to pretty much all apps - they dont know u suspended or resumed. right now x
has no idea. so when you resume - it resumes in a different state it was left
in and this leads to bugs. from userspace's point of view a device suddenly
changed its state from where it was before - for no reason userspace told it
to, nor a user directly told it. the kernel just implemented policy to turn it
on on resume, whihc unfortunately precludes ever the ability to resume and keep
it off if your wake reason was just dealing with a gsm or wifi interrupt (and
not displaying anything on the screen). if apps want the screen there are very
well defined mechanisms and protocols for them to use to indicate "please
unblank the screen so the user can see it! i need to display something". we
need to let these mechanisms be useful - currently they are broken for
suspend/resume.

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

in reality - they really should just be left as-is. imho. if wifi was off on
suspend it should damn well be off on resume, same for bluetooth or gsm or
anything else. if apps specifically care about this they can specifically track
suspend/resume. as such "ompower" (this little daemon) is doing just that -
intended to implement suspend and resume policy across all devices. that's it
job in life and has a nice dbus interface to twiddle with it. :)

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

aye. so if the kernel leaves them in the state it found them, you have a known
and predictable behavior - you don't need to do ANYTHING special UNLESS you wish
to change the state of such a device. no need to poll it just in case the
kernel decided to change it etc. and even then you end up with poll-gaps. if u
poll every second, the device may go into an unwanted state for up to 1 second
until you find out and fix it. making the polling interval shorter is just
going to eat cpu cycles and power... in the end, best to just leave everything
as you found it. if something really wants to do otherwise, it can and will.

:)

-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>