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