Forgot your password?
typodupeerror
Android Linux

Project To Mainline Android Kernel Changes Formed 73

Posted by Unknown Lamer
from the keep-on-merging dept.
ghostoftiber writes "From the article: 'Tim Bird, a Sony engineering veteran and the chair of the Architecture Group of the Linux Foundation's CE Workgroup, has announced a new concerted effort to get Android's changes to the Linux kernel back into the mainline Linux kernel tree.' Android has been using Linux 2.6.x for its devices since its release, with patches from Google. To date they haven't been merged back into the kernel mainline but existed on kernel.org. Some of the features such as wakelocks would help with Linux tablet projects, but other features aren't fully realized and support remains spotty. The radio interface layer ... still exists as an ATI/Nvidia-esque shim loader scheme with modem 'drivers' being nothing more than ihex files loaded by open code."
This discussion has been archived. No new comments can be posted.

Project To Mainline Android Kernel Changes Formed

Comments Filter:
  • Attention! (Score:3, Informative)

    by Anonymous Coward on Wednesday December 21, 2011 @12:55PM (#38450832)

    Android has been using Linux 2.6.x for it is devices since it is release, with patches from Google.

    Editors, please edit. Just once. Please.

  • by ischorr (657205)

    "Its".

    That is all.

  • RIL? Kernel? (Score:5, Informative)

    by Andy Dodd (701) <atd7@cCOWornell.edu minus herbivore> on Wednesday December 21, 2011 @12:57PM (#38450854) Homepage

    On nearly all devices the RIL is in userland.

    On Samsung GalaxyS devices, the modem was attached to a serial port and the RIL translated Android RIL function calls into modem AT commands. The kernel part of the radio interface was a serial port driver, nothing more.

    Same for most HTC devices, although some that used Qualcomm MSM implemented a pseudo-tty implemented over shared memory - but it was still AT commands being transferred. Other Qualcomm AMSS functions were implemented using an RPC-over-shared-memory interface, the kernel portion of this was small.

    Galaxy S II devices (at least GSM Exynos-based ones) have the radio hung as a USB device off of the CPU, so it did require a driver to implement. Still, most of the RIL is in userland, and the RIL belongs there.

    • by Anonymous Coward

      I assume you meant Radio Interface Layer but it took a while to figure that out. I figure I'll just help people out a bit.

      • by Andy Dodd (701) <atd7@cCOWornell.edu minus herbivore> on Wednesday December 21, 2011 @02:29PM (#38451860) Homepage

        Correct, RIL = radio interface layer in this case. I was responding to this in the summary:

        "The radio interface layer ... still exists as an ATI/Nvidia-esque shim loader scheme with modem 'drivers' being nothing more than ihex files loaded by open code."

        Now, in many cases, it is correct that hex files are being loaded by open code on initialization... but the radio baseband firmware of any phone I know of has NEVER been open source. All they are doing is bootloading a separate radio chipset, which has its own processor. It's another thing that doesn't belong in the kernel (you want scary? I have seen some cases where device firmware is stored as gigantic C arrays in header files... An example of something that should NOT be in the kernel...)

        • by Andy Dodd (701)

          So far I can't even find any reference to the RIL/modem drivers anywhere in TFA or any other links...

          Looks like just another case of the submitter being an uneducated whiner trying to sensationalize.

  • What a novel idea!!!

    • Google has been wanting those wakelocks included in the mainline for quite a while now. And it was only recently that the issue was reconsidered by Linus and the other maintainers, so that those changes were finally accepted into the mainline.

  • by Anonymous Coward

    It's better when you snort them.

  • by Doc Ruby (173196) on Wednesday December 21, 2011 @02:36PM (#38451968) Homepage Journal

    Android's source is (currently) open, and its Dalvik JVM is Apache licensed. But what about the Java class libraries to which apps link in order to run? Is their source open? Because Android's development model makes those libraries as much a part of the OS as is any of the rest of the SW Google added to the Linux kernel (ie. substituting for the GNU SW that's in most popular "Linux" distros).

    • by Anonymous Coward

      The framework classes are Apache 2, same as Dalvik.

      I'm not sure what your point is; the Android Frameworks classes and code are as relevant to the kernel as Gnome is.

      If you want a pure GPL Android framework, you are certainly welcome to cleanroom reverse engineer everything.

      • by Doc Ruby (173196)

        Thanks for the clarification on the license.

        My point was only that the framework class libraries in Android are part of the OS, even though that's not the traditional view of Java class libraries. I'm not looking for pure GPL.

  • Mainlining (Score:4, Funny)

    by ilsaloving (1534307) on Wednesday December 21, 2011 @02:54PM (#38452198)

    Just be mindful about sharing needles while mainlining. Last thing linux needs is to get a virus.

    (I'll get my coat...)

  • OK, so android is crap in lots of ways. What bothers me the most is the ever increasing incompatibilities between the older versions and the newer ones, and of course all of the vendor customizations. But what about the actual kernel mods? Are they any good? Some of them, perhaps a great number, are going to be used only by android and perhaps one or two other projects. But some may not be. Some people here are saying "don't take the patches just because they come from Google" - well, ok, not google specifi

  • by dltaylor (7510) on Wednesday December 21, 2011 @05:51PM (#38454326)

    As has been repeatedly reported, Linus is fine with someone taking a version of the Linux kernel and forking it off in their own special direction, as the Android developers have done. If you want to put some of the those features back into his main line, though, they will have to meet his standards, and those of the people he has trusted to manage the kernel changes. If the Android developers' changes were acceptable, they would already have been merged.

    "wakelocks", for example, are a kludge to cover up some very lax user-space coding standards, and are not acceptable.

    There is a lot of recent work (not really finished, IMO) to handle micromanaging power consumption for System on Chip (SoC), battery-powered devices, both in the kernel itself and through controlling userspace. If Android developers want to be using the mainstream kernel, they should be preparing to use the new interfaces and tools, while helping to find any real issues, rather than whining "why won't you just do it our way?".

    My contribution to the Linux kernel is incredibly minor, but it had to go through exactly the same vetting process, and the result was a better change.

    • No doubt at all. Everything you said is right on and I suspect that the devs at google doing kernel work would agree. The problem lies in the fact that the "not really finished" power management stuff needed to be done 3 years ago. Now there are hundreds of millions of copies of wakelock code running on real devices.

      There are user space workarounds for migration. How do you migrate drivers? Especially when you have no control over how the companies actually implementing your code.

      I don't meant to imply

  • Wakelocks were already disliked in 2009: http://lwn.net/Articles/318611/ [lwn.net]

Sigmund Freud is alleged to have said that in the last analysis the entire field of psychology may reduce to biological electrochemistry.

Working...