5 ms·

Is Android Forking from Linux?

30 points by abennett 17y ago

zppx 17y ago
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/ http://lwn.net/Articles/360343/
tvon 17y ago
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 17y ago
  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 17y ago
    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/ 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.
    - deleted 17y ago
      [deleted]
    - philips 17y ago
      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/13016 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.
      - buster 17y ago
        "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=907382 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. :)
- pmjordan 17y ago
  drivers, [..] which by nature don't need to be part of the kernel itself 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.
  - buster 17y ago
    Except that newer android releases are based on newer kernels.
    - pmjordan 17y ago
      And for every new Android device, the effort for Google to port everything increases. They probably won't do this indefinitely.
ecq 17y ago
and so it begins
tree_of_item 17y ago
Why is this a big deal?
- zppx 17y ago
  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.
- jjs 17y ago
  The fear of forking is a powerful psychological holdover from the pre-git era.
blasdel 17y ago
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 http://mjg59.livejournal.com/100221.html -- especially in contrast to his review of WebOS: http://mjg59.livejournal.com/111453.html http://mjg59.livejournal.com/111453.html
- enf 17y ago
  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.

30 points by abennett 17y ago

zppx 17y ago

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/ http://lwn.net/Articles/360343/

tvon 17y ago

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 17y ago
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 17y ago
  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/ 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.
  - deleted 17y ago
    [deleted]
  - philips 17y ago
    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/13016 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.
    - buster 17y ago
      "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=907382 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. :)
pmjordan 17y ago
drivers, [..] which by nature don't need to be part of the kernel itself 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.
- buster 17y ago
  Except that newer android releases are based on newer kernels.
  - pmjordan 17y ago
    And for every new Android device, the effort for Google to port everything increases. They probably won't do this indefinitely.

ecq 17y ago

and so it begins

tree_of_item 17y ago

Why is this a big deal?

zppx 17y ago
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.
jjs 17y ago
The fear of forking is a powerful psychological holdover from the pre-git era.

blasdel 17y ago

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 http://mjg59.livejournal.com/100221.html -- especially in contrast to his review of WebOS: http://mjg59.livejournal.com/111453.html http://mjg59.livejournal.com/111453.html

enf 17y ago
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.