

DiBona: Google will hire two Android coders to work with kernel.org - stanleydrew
http://blogs.zdnet.com/open-source/?p=6274

======
_delirium
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/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_...](http://www.theregister.co.uk/2010/02/03/android_driver_code_deleted_from_linux_kernel/)

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/>

~~~
durin42
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
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?"

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

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

