Is Android Forking from Linux?
itworld.com
itworld.com
See Matthew Garret's appraisal of it: http://mjg59.livejournal.com/100221.html -- especially in contrast to his review of WebOS: http://mjg59.livejournal.com/111453.html
Not that a fork is really a bad thing, the term has gotten a bad reputation for undeserved reasons.
At any rate, gaining acceptance into the main kernel tree can be a big deal for a driver project, but I don't think this is a problem for Android.
[edit: looks like I may have read just enough to be dangerous]
Android has introduced big new pieces of code into the Kernel including a security model called OpenBinder, a power management system called "wake locks" and a new framebuffer system. The trouble is Linux already had a security model, power management APIs and framebuffers before Android came along. So, it is alot of work to get all of this code into a shape that will mesh with what already exists in Kernel.org.
It is a fork of the Kernel at a very core level.
Getting the drivers in is just a small part of the work since it is nearly pointless getting drivers without merging in all of the things above that make Android, well, Android.
But, Google hasn't shown much resolve in fixing up its code and working with upstream.
It's just not on top of their priority list, which is fine for me. I'd rather have bugfixes and things like that as a focus before kernel inclusion. Eventually Google should hire a developer dedicated to that task. Plus, it's not like they are developing in the dark, everyone has access to http://android.git.kernel.org/ and is free to use it.
Also, we can hardly speak of a fork, as new android versions are based on newer kernel versions, which means their work has to be somewhat flexible and compatible enough to catch up with newer kernels, anyway.
Also, as i tend to think google engineers are not _that_ dumb, there may be very good reasons to write a specialized security model or framebuffer system. They probably didn't rewrite that stuff just because of the fun of it.
When I have forked projects to customize them for my own use I make the git tree public and rebase on top of the origin project to get bug fixes. Just as Android is. That doesn't mean upstream will ever take my code or that they should.
What are the good reasons for binder and wake locks? I have followed LKML discussions about them and no one has a great argument for them. If you are interested there are a great many thoughtful discussions about them e.g. http://thread.gmane.org/gmane.linux.power-management.general...
And I haven't seen the statements from Google that they want to merge with the Kernel long term either.
yep, LKML is they place they talk about it ;) -> http://thread.gmane.org/gmane.linux.kernel/905490/focus=9073...
As for the wakelock: I'm clearly not that deep into kernel development, but the thread looks like there is also no real point against wakelocks and the android developer seems to have points as to why he did what he did. In the end, we will see if their next attempt to kernel inclusion is sane and has good points to it.
Thanks for the interesting link, though! I guess i'll read up a bit on that. :)
I don't worry about out-of-tree development for odd devices too much. I wish we could merge android, but I also accept it likely being a few years away. We had similar out-of-tree issues with the SGI extreme scalability stuff, and it took quite a while before the standard kernel merged all of that.
Yes and no. The Linux kernel is very much a moving target, so getting the drivers merged means the hardware is usable for a long time. I recently tried to get the ipw2200-ap driver to build on a new-ish kernel, and so much had changed that I gave up after a while. That code is just over 3 years old; the oldest Android phone (G1/Dream) is almost 1 1/2 years old.
There was a story on HN some months ago (I can't seem to find it right now) which was about how Google had all these patches against Linux (unrelated to Android) and various other Open Source projects lying around, but never got around to submitting them back for inclusion into the main tree, which caused the code to eventually go "stale" and become essentially unmergeable. So Google are stuck with an old kernel and the rest of the world never gets to see Google's improvements. Both parties lose.