LWN on AOSP, Linux, and Rust
-
LWN ☛ In search of the AOSP community
The core of the Android operating system, as represented by the Android Open Source Project (AOSP), can only be considered one of the most successful open-source initiatives ever created; its user count is measured in the billions. But few would consider it to be a truly community-oriented project. At the 2024 Linux Plumbers Conference, Chris Simmonds asked why the AOSP community is so hard to find, and what might be done about the situation.
There are, he said, many developers working on AOSP — somewhere between 10,000 and 100,000 of them, many of whom are focused on getting Android working on a specific platform. This is not a small group of people, but they are nearly invisible. The situation is, he said, a sort of Fermi paradox — they have to be out there, but we cannot see them. He suggested comparing AOSP to the Yocto Project, which has some similar goals. Unlike AOSP, Yocto has a vibrant and highly visible community.
AOSP developers tend to work in isolation; there is little communication between teams working on AOSP, even when they are housed in the same company. AOSP developers have few opportunities to get together, share a beer, and talk about their work — or even to get together online. So these developers do not feel like part of a larger community working on common problems.
-
LWN ☛ Coping with complex cameras
Cameras were never the simplest of devices for Linux to support; they have a wide range of operating parameters and can generate high rates of data. In recent years, though, they have become increasingly complex, stressing the ability of the kernel's media subsystem to manage them. At the 2024 Linux Plumbers Conference, developers from that subsystem and beyond gathered to discuss the state of affairs and how complex camera devices should be supported in the future.
-
LWN ☛ Smart pointers for the kernel
Rust has a plethora of smart-pointer types, including reference-counted pointers, which have special support in the compiler to make them easier to use. The Rust-for-Linux project would like to reap those same benefits for its smart pointers, which need to be written by hand to conform to the Linux kernel memory model. Xiangfei Ding presented at Kangrejos about the work to enable custom smart pointers to function the same as built-in smart pointers.
-
LWN ☛ Efficient Rust tracepoints
Alice Ryhl has been working to enable tracepoints — which are widely used throughout the kernel — to be seamlessly placed in Rust code as well. She spoke about her approach at Kangrejos. Her patch set enables efficient use of static tracepoints, but supporting dynamic tracepoints will take some additional effort.
Ryhl described tracepoints as a kind of logging that records information from specific places in the kernel when they are reached. She gave binder_ioctl() as an example of a trace event in her slides; that tracepoint is triggered every time an ioctl() for Android's binderfs filesystem occurs. A developer trying to debug kernel problems can look at the log of tracepoints hit by a driver to figure out what's happening.
In C, the programmer places a tracepoint with a line that looks like a normal function call. Most of the time, this call does nothing. When in use, a programmer can attach an arbitrary function to it at run time that will be called when the tracepoint is hit. Since most tracepoints are disabled most of the time, Linux uses static keys (patching the call into the code at run time) to make this efficient.
-
LWN ☛ Improving bindgen for the kernel
Bindgen is a widely used tool that automatically generates Rust bindings from C headers. The Rust-for-Linux project uses it to create some of the bindings between Rust code and the rest of the kernel. John Baublitz presented at Kangrejos about the improvements that he has made to the tool in order to make the generated bindings easier to use, including improved support for macros, bitfields, and enums.
Baublitz noted that there has been a wishlist of features to add to bindgen for the Rust-for-Linux project for some time. After he ran into some of the same problems in his own projects, he decided to tackle them. There are three main problems that he wants to address: macro expansion, accessing bitfields via raw pointers, and supporting better conversions for Rust enums.