There's an ongoing impulse among a diversity of developers to be able to compile some or all of the Linux kernel as a library, so that a piece of software could use kernel services and APIs while running under a different kernel entirely, or a different operating system.

This time, the impulse came from Octavian Purdila, creator of the Linux Kernel Library (LKL), essentially an entire kernel compiled as a static library. He distinguished LKL from projects like User Mode Linux (UML), saying that LKL was more lightweight, having no infrastructure requirements or needing any particular sort of runtime environment.

A bunch of folks expressed interest, especially in terms of interacting with similar projects like libOS and libguestFS. And, Richard Weinberger remarked that LKL seemed to solve UML's biggest pain points: the need to use ptrace() to handle system calls and to do virtual memory management using SIGSEGV.

In a device-centric world with heavy, inefficient battery technology, there's a big incentive to figure out ways to save power. One possibility is to turn off portions of hardware when they're currently not in use, like a phone's touchscreen when the phone is in your pocket.

The difficulty lies in knowing exactly which piece of hardware to turn off, and when. If there's a clear user action, like flipping closed a flip-phone, the problem is simplified. Irina Tirdea recently tried to recognize such actions and come up with mechanisms to respond to them properly. She posted some patches to do this.

Octavian Purdila, also working on the project with Irina, described a target scenario as being when a touchscreen has been blanked but is still aware of the user's touch—through the fabric of a pocket, for example. The goal of the patches, he said, would be to save power by turning off all the hardware associated with that screen, and turn everything on again when the user activates the device.

The problem with this sort of feature is that it could be implemented along any of a number of different layers of the kernel code. The ideal location could make the difference between a complex, easily broken implementation and a simple, efficient implementation. Several folks felt that Irina and Octavian's approach was in the wrong part of the kernel, and the discussion devolved into a consideration of completely different approaches.

No consensus arose, although the allure of power-savings will undoubtedly keep the debate alive.

Mounting a filesystem under a virtual machine can be tricky. Security privileges and restrictions need to be respected, or else a filesystem could become a vector of attack by a malicious user. This particular area of kernel development also tends to have a wide appeal among companies trying to support their products, so it's possible for a variety of developers to find themselves working at cross purposes and need to accommodate each other before their patches can be accepted.

Seth Forshee and Eric Biederman, for example, recently wrote some patches to allow mounting Ext4 and FUSE filesystems by unprivileged users, ignoring the security information that otherwise might prevent those users from accessing that data.

Meanwhile, Lukasz Pawelczyk was working on code specifically to support that same security information.

A debate sprang up over the particular context involved. Andy Lutomirski suggested that if a filesystem contained a user's own data, it would be fine to override security features, on the grounds that users should be able to do what they wanted with their own data. While Casey Schaufler replied that the kernel shouldn't care what the user knew about the data, it had to follow the security protocols or else it wouldn't be able to enforce them at all.

On the other hand, as Eric pointed out, filesystems like FAT and Minix weren't capable of storing the same type of security information as more modern filesystems. There had to be a way, he said, to mount such filesystems without requiring them to support security features they couldn't support.

It's an ongoing debate. Security trumps all other considerations, including dire need, so an issue like unprivileged filesystem mounts inevitably will involve a consideration of the specific context in which a user might try to do something. Often there's some kind of crazy nuance that makes something feasible when you could have sworn it never would be feasible.