
Is Android Forking from Linux? - abennett
http://www.itworld.com/open-source/95221/is-android-forking-linux
======
blasdel
Android has never been recognizably Linux -- their systems code is almost
entirely written as if it were running on an early 80s UNIX and they had to
invent all their own modern facilities. Not surprising considering that it was
all done by the crew that developed the Sidekick, which was based on a heavily
hacked NetBSD.

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>

~~~
enf
At the time that any of the Android people were at Danger, the Sidekick had
its own custom OS written from the ground up. There was talk of switching to
NetBSD in the distant future but it hadn't happened yet.

------
tvon
Seems to be only speaking of drivers (the _/drivers/android_ directory, to be
specific), which by nature don't need to be part of the kernel itself, hence
there is no apparent fork. That's my understanding, anyway.

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]

~~~
philips
If you read Greg's blog, linked in the article, you can see that this isn't
just about the drivers.

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.

~~~
buster
While true, Google engineers have stated that they want the android source to
be in the mainstream kernel "in a long term" and i happen to believe that.

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.

~~~
philips
Having a public git tree and rebasing to new versions doesn't make it less of
a fork.

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...](http://thread.gmane.org/gmane.linux.power-
management.general/13016)

And I haven't seen the statements from Google that they want to merge with the
Kernel long term either.

~~~
buster
"We (Google) definitely want to get back in sync with mainline (as I've
mentioned earlier in this or a related thread), and we're planning on snapping
up our kernel trees to 2.6.32+ once we get past various deadlines in the near
future."

yep, LKML is they place they talk about it ;) ->
[http://thread.gmane.org/gmane.linux.kernel/905490/focus=9073...](http://thread.gmane.org/gmane.linux.kernel/905490/focus=907382)

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.
:)

~~~
buster
Linus from [http://torvalds-family.blogspot.com/2010/02/happy-
camper.htm...](http://torvalds-family.blogspot.com/2010/02/happy-camper.html):

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.

------
zppx
While it's not exactly related to the kernel, Matt Porter's presentation
slides about Android and the discussion that followed in lwn raise some good
points about the state of Android in the linux development community:
<http://lwn.net/Articles/360343/>

------
tree_of_item
Why is this a big deal?

~~~
zppx
I'm not sure if you know much about linux kernel development, but it always
was centralized, dividing efforts would be awful to linux kernel developers
that works in the embedded devices market.

