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.
"Its".
That is all.
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?
The best way to describe many of the Android changes to Linux is "utter braindamage". Seriously, are they planning to mainline Binder? Are they nuts or what?
Also, the fact that the network security extensions have "hardcoded group and user IDs" "might make mainlining difficult"? Ha!
What do these guys think Linux is, Google's playground or what?
itsits
Liam Healy
What a novel idea!!!
It's better when you snort them.
As I understand, the reason why Android kernel changes have been slow to be merged back in is that the Linux community doesn't want them; things are done differently from what the expected behavior is, and so the linux community demands that Android change its mobile architecture to conform to something that will run on someone's x86 desktop, or not.
Sony veteran? Are we mainlining some rootkit code?
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?
Thanks, I was going to look that up as well.
Much agreed with this. Mainline kernel does not need more untested kludgy garbage pushed into it from companies that didn't care to do shit right to begin with.
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.
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
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?
--
make install -not war
Why do people care so much if the Android kernel is in sync with the mainline kernel? I thought the idea behind open source was that you could take the source and do whatever you want (within the restrictions of the license but you know what I mean). Why do people make such a big deal out of forking?
Just be mindful about sharing needles while mainlining. Last thing linux needs is to get a virus.
(I'll get my coat...)
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.
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.
Hey KID! Yeah you, get the fuck off my lawn!
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 specifically no matter how much of a fanboy you are. But there is something to be said for code which has been developed by a team of highly skilled people and tested on millions of installed devices. It could be from Microsoft for all I care. If the change are good, take them. Consider the big picture: what we have here is a developing fork which we want to head off. So, what should happen is that 1) Linux(s) agrees to seriously investigate merging some of the Android patches, and (2) Google agrees to start using a Linux3 kernel (starting with the version incorporating Google changes). Google should apply their patches to this Linux3 kernel, including the patches which were not accepted into the mainline kernel. Google should NOT be forced to commit to using whichever kernel is considered modern and safe by everyone else but they should be ENCOURAGED to stay reasonably up to date, i.e. not more than a year behind the current releases.
However, even moving to a Linux3 kernel can inadvertently cause bloat which may make future versions of Android even less usable on older phones (like my G1) than they are now. So, consider where the value is in upgrading Android's kernel to Linux3. I don't have enough knowledge on this, so I will have to depend on some experts to make this decision. I hope these experts don't get paid or praised based upon how many new phones are sold...
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.
Rethinking email
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 versions depending on architecture targets should be a matter of #IFDEF or other conditional compilation at least. It really should be factored into modules, like loadable kernel modules. I personally prefer a microkernel architecture for this reason, but Linux went with monolithic kernels. The kernel build config files should give selection control, including groups per architecture tags. But a little extra that's properly shut off is OK. These gray areas are all delineated by educated guesses by the project management.
--
make install -not war
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.
Unknown Lamer? Check
GhostOfTiber? Check
Michael Crawford and a 9000-word comment about Linux that quickly turns into Cal Tech, Tsutomu Shimomura, Richard Feynman? Ahh, not yet.
I can only hope an pray you get hit by a bus and get dragged until your skin is peeled off, you POS iSheep.
... 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
If the year of the linux desktop involves horrible java-dependent crap, I'd rather it never came.
Wakelocks were already disliked in 2009: http://lwn.net/Articles/318611/
for great justice
Will this make Linux as insecure as Android?
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.