Language Selection

English French German Italian Portuguese Spanish

Kernel: Google, Xen, and Mesa

Filed under
Graphics/Benchmarks
Linux
  • Google Finally Shifting To "Upstream First" Linux Kernel Approach For Android Features

    Google's Android had been notorious for all of its downstream patches carried by the mobile operating system as well as various vendor/device kernel trees while in recent years more of that code has been upstreamed. Google has also been shifting to the Android Generic Kernel Image (GKI) as the basis for all their product kernels to further reduce the fragmentation. Looking ahead, Google is now talking of an "upstream first" approach for pushing new kernel features.

    Google's Todd Kjos talked today during Linux Plumbers Conference (LPC2021) around their Generic Kernel Image initiative. With Android 12 and their Linux 5.10 based GKI image they have further cut down the fragmentation to the extent that it's "nearly eliminated". With the Android 12 GKI, most of the vendor/OEM kernel features have now either been upstreamed into the Linux kernel, isolated to vendor modules/hooks, or merged into the Android Common Kernel.

  • Google Finally Shifting To 'Upstream First' Linux Kernel Approach For Android Feature
  • Clang-format for Xen Coding Style Checking Scheduled - Xen Project

    At the moment there is no tool that would allow to format patches in Xen. The idea of Xen-checker is to use the clang-format approach as a base for Xen ‘checkpatch’ process. The new tool consists of modified .clang-format configuration file to automate Xen patches format checking and reformatting. The tool can be used as a pre-commit hook to check and format every patch automatically. Some features are missing in the clang configurator, so new clang-format options have been proposed for more flexible code formatting. Also, the purpose of the topic is to start the discussion about the existing rules for Xen code formatting to eliminate possible inaccuracies in the work of the Xen checker. This will make it easier to adhere to the unanimous decision.

  • Mesa Merge Pending For Vulkan Ray-Tracing On Older AMD GPUs - Phoronix

    Merged yesterday for Mesa 21.3 was open-source Vulkan ray-tracing for AMD RDNA2 / RX 6000 series GPUs with the RADV driver. Opened today now is a merge request that would provide Vulkan ray-tracing with RADV to pre-RDNA2 GPUs on this driver going back to the likes of Polaris, granted the performance is another story.

    Joshua Ashton known for his work on DXVK and other Direct3D-on-Vulkan efforts for Valve has opened the merge request to enable RADV Vulkan ray-tracing for older generations of AMD GPUs.

Android to take an ?upstream first? development model for the...

  • Android to take an “upstream first” development model for the Linux kernel

    The Linux Plumbers Conference is this week, and since Android is one of the biggest distributors of the Linux kernel in the world, Google software engineer Todd Kjos stopped by for a progress report from the Android team. Android 12—which will be out any day now—promises to bring Android closer than ever to mainline Linux by shipping Google's "Generic Kernel Image" (GKI) to end-users.

    Traditionally, the Linux kernel is forked several times before it hits an Android phone, usually by each stakeholder in an Android device. First, Google forks the Linux kernel into "Android common"—the Linux kernel plus a bunch of phone- and Android-specific changes. Then SoC vendors like Qualcomm, Samsung, or MediaTek fork Android Common to make an SoC-specific kernel for each major chip release. Then each device gets a fork of the SoC kernel for device-specific hardware support.

    Android's kernel fragmentation is a huge mess, and you can imagine how long and difficult the road is for a bugfix at the top of the fork tree to reach to the bottom, where end-users live. The official Android.com documentation notes that "These modifications can be extensive, to the point that as much as 50% of the code running on a device is out-of-tree code (not from upstream Linux or from AOSP common kernels)." It's also a big time sink, and even Google phones typically ship kernels that start at two years old.

    Google has been on a journey to lessen the distance between Android and Linux with the GKI. The goal is for Google to fork the Linux kernel once for Android, instead of three times, and give SoC and device manufacturers space for their customizations via plug-in modules.

Google is bringing Android closer to the Linux kernel

  • Google is bringing Android closer to the Linux kernel

    Google has shared more details about how it aims to bring the Android kernel a lot closer to the mainline Linux kernel with the impending release of Android 12.

    The news came courtesy of a presentation at the Linux Plumbers Conference by Google’s software engineer Todd Kjos.

    Commenting on the development, Ars Technica shares that typically the mainline Linux kernel goes through three major forks before it is shipped to the end users on an Android device.

Google plans to bring Android's kernel closer to the Linux...

  • Google plans to bring Android's kernel closer to the Linux upstream

    Google has spent nearly half a decade attempting to make it easier for OEMs to keep their devices updated, most notably with the introduction of Project Treble in 2017. The company has previously proposed efforts to bring Android closer to the Linux kernel, something it's finally attempting with the upcoming release of Android 12. At this week's Linux Plumbers Conference, Google laid out how it's planning to accomplish its lofty goal.

    As reported by Ars Technica, Android is moving to a new "upstream" model and away from the traditional forked layout that can cause software delays. Before a device is upgraded, the Linux kernel goes through multiple forks — from Linux into "Android common," then into the SoC-specific version, before finally reaching its device-specific iteration. That's a ton of work for every company involved, and it's one of the main contributing factors to Android's fragmentation issue.

Android is shifting to an “upstream first” development model

  • Android is shifting to an “upstream first” development model for new Linux kernel features

    But what’s coming next is even more important, and is arguably the most important part of Google’s long-term strategy. When we pointed out earlier how Treble modularized Android by separating the OS framework from the vendor implementation, we included the “device-specific Linux kernel fork” as part of that vendor code. Anyone who’s familiar with Linux on desktops will recognize a problem there: Why is it lumped in with closed-source vendor code? The problem is that while Android devices do ship with the Linux kernel, that kernel features a lot of out-of-tree code.

Google will move to develop innovations for Android...

  • Google will move to develop innovations for Android in the main Linux kernel

    At the last Linux Plumbers 2021 conference, Google spoke about the success of the initiative to move the Android platform to use a regular Linux kernel instead of using its own version of the kernel, which includes changes specific to the Android platform.

    The most important development change was the decision to move after 2023 to the “Upstream First” model, which implies the development of all new kernel features required in the Android platform directly in the main Linux kernel, and not in its separate branches (functionality will be promoted to the main kernel, and then used in Android, and not vice versa). In 2023 and 2024, it is also planned to transfer to the main core of all additional patches remaining in the Android Common Kernel branch.

    As for the near future, for the Android 12 platform expected in early October, assemblies of the Generic Kernel Image (GKI) kernel will be offered, as close as possible to the usual 5.10 kernel. For these assemblies, a regular release of updates will be provided, which will be placed in the ci.android.com repository. In the GKI kernel, Android-specific additions, as well as hardware-related handlers from OEMs, are moved into separate kernel modules. These modules are not tied to the main kernel version and can be developed separately, which greatly simplifies the maintenance and transfer of devices to new kernel branches.

Google Working to Bring Android Closer to Linux Kernel

  • Google Working to Bring Android Closer to Linux Kernel

    Google is working to bring Android closer to the Linux kernel in a move that could significantly speed up development time.

    Android is arguably the biggest Linux-based operating system (OS) in existence, powering billions of devices the world over. Unfortunately, the OS is a far cry from the base Linux kernel, being forked several times before it gets to a user’s device. The first fork occurs when Google takes the Linux kernel to create the base Android kernel, and then again by each chip maker, and yet again by device manufacturers.

    The end result of repeated forking is that it can take a significant amount of time for improvements, features and fixes to make their way from the top all the way to the end user.

Google plans to use regular Linux kernel for Android

  • Google plans to use regular Linux kernel for Android - itsfoss.net

    Google plans to change the process of preparing the Linux kernel for Android. Currently, before the kernel is ready for use on the target Android device, a number of actions are performed on it.

    The circuit looks something like this:
    LTS Kernel Linux → Android Common Kernel → Vendor Kernel → OEM/Device Kernel

    First, Google creates a fork of the regular LTS Linux kernel, then a lot of patches that are specific to Android phones are applied to it. Thus, the core is obtained – Android Common. Then chip makers like Qualcomm, Samsung or MediaTek fork Android Common and form the Vendor Kernel for their chips. Then the OEM / Device Kernel is formed from the Vendor Kernel for hardware support for a specific device.

    Thus, before the initial kernel reaches the final state, you have to go a long way in applying patches and other preparatory actions. This process can be delayed for a long time, you have to solve a lot of problems, catch errors, and conduct testing cycles.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Stable Kernels: 5.14.13, 5.10.74, 5.4.154, 4.19.212, 4.14.251, 4.9.287, and 4.4.289

I'm announcing the release of the 5.14.13 kernel.

All users of the 5.14 kernel series must upgrade.

The updated 5.14.y git tree can be found at:
	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.14.y
and can be browsed at the normal kernel.org git web browser:
	https://git.kernel.org/?p=linux/kernel/git/stable/linux-s...

thanks,

greg k-h
Read more Also: Linux 5.10.74 Linux 5.4.154 Linux 4.19.212 Linux 4.14.251 Linux 4.9.287 Linux 4.4.289

Android Leftovers

Review: Auxtral 3

At the beginning of this review I mentioned Auxtral reminded me of Linux Mint Debian Edition. The theme, the Cinnamon desktop, and general look of the project certainly held that first impression. However, the default applications and tools (apart from the Cinnamon desktop and command line utilities) felt quite a bit different. Linux Mint has been around for several years and has earned a reputation for being beginner friendly, polished, and shipping with a lot of top-notch open source applications. Auxtral appears to have a similar approach - similar base distribution, the same desktop environments, and a similar look. However, Auxtral does have its own personality under the surface. It ships with a quite different collection of applications, sometimes using less popular items (Brave in place of Firefox, SMPlayer instead of VLC, etc.) It has also gone its own way with software updates, preferring classic tools like APT and Synaptic over Mint's update manager. Auxtral is off to a good start. This was my first time trying the distribution and the experience was mostly positive. The operating system is easy to install, offers multiple desktop environments, and walks a pretty good line between hand holding and staying out of the way. The application menu is uncluttered while including enough programs to be useful. Some of those programs are a bit more obscure or less beginner friendly than what you might find in Linux Mint, but otherwise it's a good collection. Virtually everything worked and worked smoothly. I was unpleasantly surprised by this distribution's memory usage, most projects consume about half as much RAM, but otherwise I liked what Auxtral had to offer. I might not recommended it to complete beginners, especially since the project does not appear to have any documentation or support options of its own, but for someone who doesn't mind a little command line work or who likes the idea of an easy to setup distribution that combines Debian with the Cinnamon (or Xfce desktop) this seems like a good option. Read more

31 Best Linux Performance Monitoring Tools

Linux Performance Monitoring tools are the tools that allow you to keep track of your Linux system's resources and storage usage, as well as the state of your network. The tools can be used to troubleshoot and debug Linux System Performance issues. In this tutorial, we will learn the best tools for Linux performance monitoring and troubleshooting. Read more