News

Google experimenting with Linux kernel 3.8, could be readying it for Key Lime Pie

12

Some unexciting exciting news for you today, folks, if that makes sense. Google seems to be experimenting with version 3.8 of the Linux kernel as the code was found in the company’s repositories. This normally wouldn’t mean too much to us, but with such a major jump from what’s running in Jelly Bean 4.2.2 — kernel version 3.4 — there’s reason to take notice.

For starters, this version includes more Android-related code, including driver support for NVIDIA Tegra drives, and advancements in code for Samsung Exynos DRM. Also important to us mobile folks is a lower memory footprint, with Phoronix saying it uses “a lot less memory” than versions prior. This is a huge deal for mobile, of course, where memory is more limited than on desktop and laptop computing. Finally, Samsung’s F2FS file system was merged into the kernel, a file system that’s said to be very flash-friendly.

Google is far along in these “experimental stages,” apparently, and while we might not have confirmation yet it’s possible the kernel is being readied for use inside Android 5.0 Key Lime Pie. We likely won’t be getting official details regarding that particular version of Android until Google I/O this summer, so just sit back and enjoy this news for what it is for the time being.

[via Phoronix]

Quentyn Kennemer
The "Google Phone" sounded too awesome to pass up, so I bought a G1. The rest is history. And yes, I know my name isn't Wilson.

Nexus 4, Nexus 10 found to have OpenCL drivers

Previous article

Google says Motorola’s device pipeline wasn’t “Wow” worthy, downplays Samsung worries

Next article

12 Comments

  1. The Linux kernel is advancing so fast! (a new version is coming every 2 or 3 months) and it is indeed the most awesome opensource piece of software!

    1. Indeed, for things very large (data servers, etc) and very small (cell phones) Linux is the ultimate expression of what open source is and can be.

  2. My Note 10.1 JB is running on an old 3.0.31, which is even earlier than my two chinese A10 tablets that are based off 3.0.8+. It’s great that Google experiments with new kernels, but at the end of the day it’s OEMs, who decide on what’s more stable. Especially Samsung, who has no desire to reveal all Exynos bells and whistles.

  3. The linux kernel is indeed moving fast, but I’d be cautious to report that Google is moving to 3.8 for specific reasons. They have a really good practice of keeping their software updated and retiring end-of-life code for newer versions, just to keep up with today’s technology. Sure, the lower memory footprint and Samsung’s flash-friendly FS are good reasons to adopt, but so are all the security issues found in the 3.0 to 3.7 trees over the past two weeks. We’ve had a ptrace race exploit, and an AF_NETLINK device exploit, both allowing an attacker to elevate privileges to root. Those alone are good reasons to consider upgrading.

    Remember a year or so ago when Google was experimenting with the BFS scheduler to replace CFS + Cgroups? There were a number of repos created publicly for this process, but none of them ended up being used in Android, and the entire project was scrapped. BFS just was too unpredictable. Google tries new things all the time, and some of them just don’t pan out the way they hope for – but that’s how you learn, after all. Just because there’s a 3.8 tree floating around from Google doesn’t mean it’s going to be used any time soon, if ever. And if it is, who knows what features it will or won’t have – when you compile the Android kernel, it’s like a buffet – you pick and choose what you want, and what you don’t, so you end up with a very specific set of features for your system (your plate), that may or may not be representative of what all is actually available (the buffet). At least, that’s how it’s *supposed* to be done. Kitchen sink kernels (which include everything) are around, but usually found in general linux distributions for installation on a swath of PCs where compatibility is required for just about every device under the sun. I loathe those types of installs. (Gentoo user here, does it show?)

    1. Good post

    2. Nice comment dude

    3. Lost me on line 3

  4. It’s nice that kernel 3.8 may come with KLP, but i doubt it’s ready yet. Also, it’s an exaggeration to say that the ‘zero huge_page’ support will be a “huge deal” for Android. If anything it’ll be minor.

    What I’m really hoping for is further work on responsiveness of the UI (iOS is still better in that regard), unification in Messaging apps (iOS is better here too with iMessage), more robust Google Now with better voice support, etc. The user experience is what I’m getting at that still needs the most work.

    Of course, every little bit helps with these backend improvements too.

  5. Can’t wait to switch to F2FS. ExFAT is MSFT proprietary suckage, thus many of us still have to fallback to FAT32 on CyanogenMod et al on our external sdcards.

  6. The linux kernel 3.8 uses 30% less memory than before on my system (ubuntu 13.04). It’s very good to see a desktop system using just 280MB of ram (3 GB available on my laptop).

  7. > Google seems to be experimenting with version 3.8 of the Linux kernel as the code was found in the Company’s Repositories. This normally wouldn’t mean too much to us, but with such a major jump from what’s running in Jelly Bean 4.2.2 — kernel version 3.4 — there’s
    reason to take notice.

    The 3.6.x and 3.7.x Kernel are EOL, 3.8 is the next Stable Version; that is the reason for the jump. Don’t be surprised it they go to 3.9 by the time KLP gets pushed since it may be ready in a month or three.

    The newest Kernel is important for speed, features and security. The cost to test it (for Android purposes) is less than the cost to test each and every Version as it comes out. Jumping saves Money if you do not jump too far (beyond what you are willing to fix and Bugs you are willing to live with).

    It is the Carriers holding back the Updates that makes ‘non-Google Android Devices’ poor Candidates (for bleeding edge Kernels) since they are inhibited from hot-fixes (neccesary when you discover too late that you jumped too far).

Leave a reply

Your email address will not be published. Required fields are marked *