Hacker News Reader

Couldn't Android change their wakelock interface to satisfy the mainline devs and then distribute some kind of low level backwards-compatibility layer to keep existing apps/drivers from breaking?

View on HN

From what I can tell, the "change" to satisfy them would be removing it entirely. It's not an interface problem, it's the entire concept: it's critical for what Google is doing, but perhaps not at all desired for desktops or servers.

I can't seem to find it now, but there was at least one experienced kernel dev in one of the threads or discussions somewhere who seemed to think merging something to accommodate Google's concerns was possible, if they were willing to make significant changes. I wish I could find it, but it seemed to be proposing that Google would have the best luck if they could pare down their patch to a set of base functionality that the existing power-management API doesn't support that absolutely needs to be in the kernel for what they want to do; and then have the rest done in a daemon outside the kernel.

I can see why Google wouldn't want to do that also; sort of a collision of interests. Google has a solution that works today, and works fine for Android. But the mainline kernel is trying to maintain a general-purpose API. So the best solution for Google is to make a simple, clean, but special-purpose hack for Android. But the kind of solution mainline would like to have is for someone to factor out a minimal set of general hooks that need to go into the kernel, and then farm out more specialized needs to system-level daemons or userland. But factoring stuff like that is always harder.

Reply on news.ycombinator.com