Proposal: "debug" branch for the kernel

Werner Almesberger werner at
Wed Jul 9 16:17:27 CEST 2008

Andy Green wrote:
> I agree that a holistic view is hard to come by, but it's hard to come
> by for real reasons, the whole "stack" from:
> ~ - fine hardware decisions through
> ~ - application stacks

- user perception

Yes, that's exactly the problem. Linux suspend/resume comes from the
PC world, and what it really means is "power off but be prepared to
power on again quickly". Then some exceptions are added to this rule.

In our case, we're a lot more aggressive, we want to "power off"
automatically, and we have a lot more things that could want to be
kept alive through suspend.

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.

Worse yet, this may need some synchronization among applications,
but if they all only talk to the kernel, they get confused among each

That's why I'm so happy about finally getting that user space daemon.
It sits in the middle between kernel and applications, cutting the
depth of abstraction on both sides roughly in half. It also gives us
a slow-moving interface.

- Werner

More information about the openmoko-kernel mailing list