4 ms·

DiBona: Google will hire two Android coders to work with kernel.org

42 points by stanleydrew 17y ago

_delirium 17y ago
For some background, One of the main sticking points is Google's wakelocks mechanism, which the kernel folks don't consider appropriate, but coming up with a useful replacement has stalled (esp. since a decent number of kernel.org folks think existing functionality is sufficient, which Google disagrees with). Here's two posts from last February on that: http://lwn.net/Articles/318611/ http://lwn.net/Articles/318611/ , http://lwn.net/Articles/319860/ http://lwn.net/Articles/319860/ In February this year, the Android drivers in the staging tree were removed, because there was no real progress on merging them, mainly again due to wakelocks and a few other issues: the drivers use wakelocks, and the mainline kernel has no interest in merging that framework as is; a mutually acceptable replacement for them hasn't emerged, so the drivers can't be merged either: http://www.theregister.co.uk/2010/02/03/android_driver_code_deleted_from_linux_kernel/ http://www.theregister.co.uk/2010/02/03/android_driver_code_... DiBona's view on it at that time was rather less conciliatory, essentially that kernel.org doesn't care about mobile platforms, so there's no point in dealing with them, which spawned a bit of a flamewar: http://lwn.net/Articles/372568/ http://lwn.net/Articles/372568/
- durin42 17y ago
  I think DiBona's position was and is eminently reasonable. As I understand things, the Android team tried to upstream wakelocks, and the kernel maintainers basically said no, but without any proposal for something better. To my mind, that's begging for a fork. If it were _me_ getting that kind of feedback on a patch, it either means the functionality from the patch is completely unwelcome or that I'm supposed to guess the maintainer's mind on things. I've had this happen with patches, and I've had to call out a maintainer as being unreasonable in this regard. It was ugly, and I don't think I'd bother again, I'd just maintain and ship a patched version. Disclaimer: I work for Google, and enjoy spending time with Chris. His office makes my job more fun.
  - _delirium 17y ago
    I can see some of both sides. From the kernel developers' perspective, wakelocks solve a special-case problem: they only work on systems where frequent suspend/resume is possible (e.g. ARM/SoC style devices), have tight kernel/app integration, and accepting them means basically forking the power-management support within the kernel, with one system for Android-style devices, and another system for everyone else. They'd prefer a more unified power-management API, but solving that problem in a way that works for everyone is a lot harder. AFAICT, nobody on either side has put much effort into solving that general API problem. Not sure who to blame for that, but in theory, the maintainers of the current power-management API could've put forth a counter-proposal for how to accommodate Android's concerns in their framework; or Google could've put forth a revised proposal for how to merge wakelocks-like functionality with the existing power-management API. Some of it might just be a mismatch between how the kernel process works and how Google usually does things. The convention is that when you submit an API-changing patch upstream, you're proposing: I think all users of Linux should have this new API, and you have to be prepared to defend the API design, modify it in response to criticism or concerns, etc. Ideally, you're supposed to get feedback from other potential users before you actually write the code, as opposed to designing everything unilaterally and presenting it as a done deal. From what I can tell, Google's approach was just a one-off: here's what we propose, and btw we already shipped it. Basically, skipped the step where they were supposed to first propose it and ask for feedback. An approach that might've gotten more positive results would be, before sending off the patch, send a short design proposal with something like: "Hey, for our needs we're thinking of the following API, because [explain why existing APIs are insufficient], and [explain rationale and use cases for this one]. What do people think?"
- chbarts 17y ago
  But isn't Linux already on mobile and embedded platforms? What makes the Android so special in this regard?
  - durin42 17y ago
    wakelocks solve a very specific power management concern. Historically power management in Linux hasn't been tightly integrated with apps, which is desirable on a smartphone.
- guelo 17y ago
  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?
  - felixc 17y ago
    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.
    - _delirium 17y ago
      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.
wmf 17y ago
I wonder how many Android kernel coders Google has now; this may put a number on the cost of getting your code upstream.
cdibona 17y ago
Actually, I don't think I said this exactly. I think I said "We are hiring." We have way more than 2 reqs for android and non-android related kernel work. I think I might have said that I can see hiring a few people just to do kernel pushes.

42 points by stanleydrew 17y ago

For some background, One of the main sticking points is Google's wakelocks mechanism, which the kernel folks don't consider appropriate, but coming up with a useful replacement has stalled (esp. since a decent number of kernel.org folks think existing functionality is sufficient, which Google disagrees with). Here's two posts from last February on that: http://lwn.net/Articles/318611/ http://lwn.net/Articles/318611/ , http://lwn.net/Articles/319860/ http://lwn.net/Articles/319860/ In February this year, the Android drivers in the staging tree were removed, because there was no real progress on merging them, mainly again due to wakelocks and a few other issues: the drivers use wakelocks, and the mainline kernel has no interest in merging that framework as is; a mutually acceptable replacement for them hasn't emerged, so the drivers can't be merged either: http://www.theregister.co.uk/2010/02/03/android_driver_code_deleted_from_linux_kernel/ http://www.theregister.co.uk/2010/02/03/android_driver_code_... DiBona's view on it at that time was rather less conciliatory, essentially that kernel.org doesn't care about mobile platforms, so there's no point in dealing with them, which spawned a bit of a flamewar: http://lwn.net/Articles/372568/ http://lwn.net/Articles/372568/

durin42 17y ago
I think DiBona's position was and is eminently reasonable. As I understand things, the Android team tried to upstream wakelocks, and the kernel maintainers basically said no, but without any proposal for something better. To my mind, that's begging for a fork. If it were _me_ getting that kind of feedback on a patch, it either means the functionality from the patch is completely unwelcome or that I'm supposed to guess the maintainer's mind on things. I've had this happen with patches, and I've had to call out a maintainer as being unreasonable in this regard. It was ugly, and I don't think I'd bother again, I'd just maintain and ship a patched version. Disclaimer: I work for Google, and enjoy spending time with Chris. His office makes my job more fun.
- _delirium 17y ago
  I can see some of both sides. From the kernel developers' perspective, wakelocks solve a special-case problem: they only work on systems where frequent suspend/resume is possible (e.g. ARM/SoC style devices), have tight kernel/app integration, and accepting them means basically forking the power-management support within the kernel, with one system for Android-style devices, and another system for everyone else. They'd prefer a more unified power-management API, but solving that problem in a way that works for everyone is a lot harder. AFAICT, nobody on either side has put much effort into solving that general API problem. Not sure who to blame for that, but in theory, the maintainers of the current power-management API could've put forth a counter-proposal for how to accommodate Android's concerns in their framework; or Google could've put forth a revised proposal for how to merge wakelocks-like functionality with the existing power-management API. Some of it might just be a mismatch between how the kernel process works and how Google usually does things. The convention is that when you submit an API-changing patch upstream, you're proposing: I think all users of Linux should have this new API, and you have to be prepared to defend the API design, modify it in response to criticism or concerns, etc. Ideally, you're supposed to get feedback from other potential users before you actually write the code, as opposed to designing everything unilaterally and presenting it as a done deal. From what I can tell, Google's approach was just a one-off: here's what we propose, and btw we already shipped it. Basically, skipped the step where they were supposed to first propose it and ask for feedback. An approach that might've gotten more positive results would be, before sending off the patch, send a short design proposal with something like: "Hey, for our needs we're thinking of the following API, because [explain why existing APIs are insufficient], and [explain rationale and use cases for this one]. What do people think?"
chbarts 17y ago
But isn't Linux already on mobile and embedded platforms? What makes the Android so special in this regard?
- durin42 17y ago
  wakelocks solve a very specific power management concern. Historically power management in Linux hasn't been tightly integrated with apps, which is desirable on a smartphone.
guelo 17y ago
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?
- felixc 17y ago
  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.
  - _delirium 17y ago
    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.

wmf 17y ago

I wonder how many Android kernel coders Google has now; this may put a number on the cost of getting your code upstream.

cdibona 17y ago

Actually, I don't think I said this exactly. I think I said "We are hiring." We have way more than 2 reqs for android and non-android related kernel work. I think I might have said that I can see hiring a few people just to do kernel pushes.