Slashdot Mirror


Project To Mainline Android Kernel Changes Formed

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

10 of 73 comments (clear)

  1. Attention! by Anonymous Coward · · Score: 3, Informative

    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.

    1. Re:Attention! by Raenex · · Score: 5, Funny

      It's a loosing battle, now.

  2. RIL? Kernel? by Andy+Dodd · · Score: 5, Informative

    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.

    --
    retrorocket.o not found, launch anyway?
  3. Re:Oh, no. by GuB-42 · · Score: 3, Informative

    Linux is everyone's playground.

    Google and the mainline developers hold different point of view. For Google, the kernel is just a component of their OS, this is the reason why they can get away with hacks that mainline developers view as brain damage. They just need to get it to work with Android.

    Trying to merge the mainline kernel with Android is just a bonus witch benefits both parties.

  4. Re:Oh, no. by JonahsDad · · Score: 5, Funny

    Linux is already so retarded that I doubt anybody will notice. We've long reached the stage where there's far too much stuff in the mainline kernel. Every other option is now "WTF is this?" -- where I once understood every single configuration option.

    Linus, you don't have to post as an AC.

  5. Re:Radio Interface Layer? Kernel? by Anonymous Coward · · Score: 3, Informative

    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.

  6. Re:Radio Interface Layer? Kernel? by Andy+Dodd · · Score: 3, Informative

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

    --
    retrorocket.o not found, launch anyway?
  7. Mainlining by ilsaloving · · Score: 3, Funny

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

    (I'll get my coat...)

  8. Re:Why bother? by olau · · Score: 3, Insightful

    Because it aids collaboration, avoids duplication of effort, leaves more room for innovation from more people, more eyes make the bugs shallower, etc. The things that make open source a success to begin with.

    If you think open source is all there is to open source, you don't understand it properly.

  9. Re:Just say Nay! by dbc · · Score: 3, Insightful

    Exactly. Google is being outrageously arrogant, IMHO. If you want your stuff in the kernel, submit a patch that Linus is happy with -- Google somehow believes that their stuff should get merged just because they are Google.

    Clue for Google: IBM, Intel, and every other major player has coded, re-coded, re-re-coded, and absorbed and acted upon LKML input, without getting their feelings hurt (leastwise they didn't whine about it publicly).

    It would be best for all concerned if Google's *good* ideas were put in a form that Linus and the LKML are happy with, and merged. The bad ideas should be left out. And merging cruft just because it is from Google is a Really Bad Idea. Cruft is cruft.