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."
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.
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?
Monty Python's Flying Circus!
Give me Classic Slashdot or give me death!
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.
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.
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.
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?
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).
--
make install -not war
Just be mindful about sharing needles while mainlining. Last thing linux needs is to get a virus.
(I'll get my coat...)
While there may be some truth in this, look at it from the other side of the table. It's a bad idea to take a badly fitting half-baked component thrown over the wall and merge it in, just to shut up a contributor. That's not how you survive in the long term as an open source project.
just a bonus witch
Gotta love those bonus witches.
AccountKiller
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.
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.
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.
... but you can't reuse something that is of sufficiently low quality, whether it is in the mainline kernel or not. And a lot of the drivers associated with Android fall into this category, or at least the ones I have reviewed. Google clearly isn't All That on the driver side, by far. (Or in the HAL code in Android, for that matter, but that is a different topic).
And I have never been convinced that runtime-PM wasn't a technically better solution than Wakelocks, either. So I really haven't lost any sleep over the latter not being in mainline.
b.g.
Knowing next to nothing about what makes kernel code good or cruft what did Google submit that is cruft?
I am not a partisan in this, I really want to know. I chose to ask this question here because you seem passionate about this. I read a bit about the wake lock driver changes forever ago. There seemed to be a lot of disdain for that model at the time.
Aside from that, is there something that the OS community could do to help inform google? I ask only because android seems to be a wonderful means to an end. More than anything before it android could actually make this the year of the linux desktop. (I feel dirty for having said that)
grape - the GNU free, open source rape