Project To Mainline Android Kernel Changes Formed 73
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."
Attention! (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.
Re: (Score:1)
Yet they contract it to it is to it's. We are fighting a losing battle.
Re:Attention! (Score:5, Funny)
It's a loosing battle, now.
Re: (Score:3)
If we give you enough +Funnys, will it eventually bump to Score:6?
Re: (Score:2)
No it wont.
Re: (Score:2)
For all intensive purposes, I could care less.
Re: (Score:1)
For all intensive purposes, I could care less.
Supposively, their all the same thing anyway.
Mandatory angryflower link (Score:1)
itsits [angryflower.com]
Re: (Score:2)
Android has been using Linux 2.6.x for it's devices since it's release
Now they changed it to this. What have you done?!
Re: (Score:2)
its. (Score:2)
"Its".
That is all.
Re: (Score:3)
Monty Python's Flying Circus!
Re: (Score:2)
time for something completely different
Re: (Score:2)
just sleeping
Re: (Score:2)
No, that WOULD be "it's" =)
Re: (Score:2)
Monty Python's Flying Circus!
I prefer their original name, Owl-Stretching Time.
Stupid BBC.
RIL? Kernel? (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.
Re:Radio Interface Layer? Kernel? (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.
Re:Radio Interface Layer? Kernel? (Score:4, 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...)
Re: (Score:2)
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.
Re:Oh, no. (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.
Re: (Score:1)
A kingdom for some mod points!!!
Re: (Score:1)
A kingdom for some mod points!!!
There you go. I modded GP "Funny" for you. I'll take that kingdom now.
(Posting AC in order to not undo the modding and lose my kingdom, of course).
Re: (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.
Re: (Score:3)
just a bonus witch
Gotta love those bonus witches.
Submitting contributions upstream? (Score:2)
What a novel idea!!!
Re: (Score:2)
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.
Don't mainline kernel changes (Score:1)
It's better when you snort them.
Re: (Score:3)
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.
Re: (Score:2)
on top of that there is a history of not accepting patches that cause regressions in some loads, especially when those loads are server ones. The linux kernel community seems to not want them, but in reality they want them to work in/on all systems/platforms.
Anyways, all of that said as nothing more than a long term linux user, as i'm not a kernel dev or anything like one.
Re: (Score:2)
Sony produces Android phones (or outsources, the difference is not relevant here), so they too write drivers for phones.
Also, as far as I know, there is no evidence indicating that their technical personel is as unethical as their executives, so I'm quite willing to trust them. Besides, it is free software, and rootkit would need to be public.
Re: (Score:1)
Re: (Score:2)
I don't see why Android patches that aren't more or less universal in installation target should be in the mainline kernel. Isn't that exactly what source tree branches are for? Regardless of their quality (which should only determine whether they're committed, not where they're committed) if their features are out of scope of the mainstream, why would they be committed to the mainstream branch?
Re: (Score:2)
I don't see why Android patches that aren't more or less universal...
The more or less part is the bit that worries me. When Novell or Redhat or anyone else submits kernel enhancements or patches they are doing so in concert with many other stake holders. What Google and other less reputable entities want to do is back rev the kernel to support Android specifically an OS unto itself if you will and thus will be Android specific. Android has shown itself to be both pretty buggy and having security issues, even in Ice Cream Sandwich.
Re: (Score:2)
Well as I said, bugs/quality are one issue that should prevent committing to any "live" branch used for building on actual devices.
But the universality of code is always a call by the project management. There's plenty of code that can be compiled into machines on which it will not run, so long as logic prevents it running there. The extra size of the OS image isn't that big a problem, so long as it's not being executed (and the logic that stops it isn't being executed too much). Generating different versio
Re:Just say Nay! (Score:4, 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.
Re: (Score:2)
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 e
Re: (Score:2)
The only community input that matters here is that from LKML. The LKML is the judge of cruft. Google knows how to find LKML. Every other company that wants code in the mainline joins the LKML community as a *peer* and leaves the attitude behind.
Re: (Score:2)
I'd be glad if drivers for all that stuf that goes into phones were availabe at the kernel. It would make it way easier to create other kinds of computers.
But I do understand you are concerned about code quality. The problem is that quality won't start improving if people don't start to reuse their drivers, and people won't reuse drivers if they are not at the main kernel. It is quite ok to ask for a driver that won't cause problems for other code, it is not ok to ask for a driver that doesn't have bugs.
Re: (Score:3)
... 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 slee
OSS Android Libraries? (Score:3)
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).
Re: (Score:1)
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.
Re: (Score:2)
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.
Re:Why bother? (Score:4, 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.
Mainlining (Score:4, Funny)
Just be mindful about sharing needles while mainlining. Last thing linux needs is to get a virus.
(I'll get my coat...)
baby, bathwater, which direction? (Score:2)
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
no freaking way, please!!! (Score:3)
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.
Re: (Score:1)
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
How is this new? (Score:1)