Proposal: "debug" branch for the kernel

Andy Green andy at
Wed Jul 9 16:39:42 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

| If you add all this to the kernel, it just keeps on growing: first
| the charger LED, then the backlight, maybe a "GSM call in progress"
| mode next, then perhaps "VoIP in standby", etc. And even if you
| implement all these states and modes in the kernel, chances are that
| you don't fully understand what applications want, and vice versa.

You will still need piecemeal incomplete support in kernel for what's
powered and what's not, with no actual architecture.  This is not a win
for our products but a sticky quick workaround because we failed to
define the whole issue and find the optimal way, partly due to some
weird userspace vs kernel dogma clouding minds today...  but mainly
because the full scope of what it needs to do is broad.

Carsten's main goal seems as simple as "suspend if you can" and "you
can't suspend now", something trivial in kernel and perfectly handling
crashed apps, etc.

| That's why I'm so happy about finally getting that user space daemon.

Oh?  You plan to write that daemon or even talk to it?  Cool.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list