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."
This is stupid very very stupid.
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
Lite is s7raini8g
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.
I for one don't want half baked Android ( hurry push it out so we can one up Apple's IOS ) garbage in my Linux Kernel thank you.
Android is being pushed by god alone knows how many companies doing their own patches and coordinating with no one. While I am perfectly comfortable with them doing their own thing on their own devices I don't want their kludges to drift back into my server or desktop kernel.
I can only hope and pray that Linus sees his and just tells them to fuck off.
Hey KID! Yeah you, get the fuck off my lawn!
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.
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
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...)
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...
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.
Wakelocks were already disliked in 2009: http://lwn.net/Articles/318611/
for great justice
Will this make Linux as insecure as Android?