New LWN Articles on Kernel: QEMU, BPF, and C
-
Accessing QEMU storage features without a VM [LWN.net]
The QEMU emulator has a sizable set of storage features, including disk-image file formats like qcow2, snapshots, incremental backup, and storage migration, which are available to virtual machines. This software-defined storage functionality that is available inside QEMU has not been easily accessible outside of it, however. Kevin Wolf and Stefano Garzarella presented at KVM Forum 2022 on the new qemu-storage-daemon program and the libblkio library that make QEMU's storage functionality available even when the goal is not to run a virtual machine (VM).
Like the Linux kernel, QEMU has a block layer that supports disk I/O, which it performs on behalf of the VM and supports additional features like throttling while doing so. The virtual disks that VMs see are backed by disk images. Typically they are files or block devices, but they can also be network storage. Numerous disk-image file formats exist for VMs and QEMU supports them, with its native qcow2 format being one of the most widely used. The QEMU block layer also includes long-running background operations called blockjobs for migrating, mirroring, and merging disk images.
-
More flexible memory access for BPF programs [LWN.net]
All memory accesses in a BPF program are statically checked for safety using the verifier, which analyzes the program in its entirety before allowing it to run. While this allows BPF programs to safely run in kernel space, it restricts how that program is able to use pointers. Until recently, one such constraint was that the size of a memory region referenced by a pointer in a BPF program must be statically known when a BPF program is loaded. A recent patch set by Joanne Koong enhances BPF to support loading programs with pointers to dynamically sized memory regions.
-
Would you like signs with those chars? [LWN.net]
October 24, 2022 Among the many quirks that make the C language so charming is the set of behaviors that it does not define; these include whether a char variable is a signed quantity or not. The distinction often does not make a difference, but there are exceptions. Kernel code, which runs on many different architectures, is where exceptions can certainly be found. A recent attempt to eliminate the uncertain signedness of char variables did not get far — at least not in the direction it originally attempted to go.
As a general rule, C integer types are signed unless specified otherwise; short, int, long all work that way. But char, which is usually a single byte on current machines, is different; it can be signed or not, depending on whatever is most convenient to implement on any given architecture. On x86 systems, a char variable is signed unless declared as unsigned char. On Arm systems, though, char variables are unsigned (unless explicitly declared signed) instead.
The fact that a char variable may or may not be signed is an easy thing for a developer to forget, especially if that developer's work is focused on a single architecture. Thus, x86 developers can get into the habit of thinking of char as always being signed and, as a result, write code that will misbehave on some other systems. Jason Donenfeld recently encountered this sort of bug and, after fixing it, posted a patch meant to address this problem kernel-wide. In an attempt to "just eliminate this particular variety of heisensigned bugs entirely", it added the -fsigned-char flag to the compiler command line, forcing the bare char type to be signed across all architectures.
This change turned out to not be popular. Segher Boessenkool pointed out that it constitutes an ABI change, and could hurt performance on systems that naturally want char to be unsigned. Linus Torvalds agreed, saying that: "We should just accept the standard wording, and be aware that 'char' has indeterminate signedness". He disagreed, however, with Boessenkool's suggestion to remove the -Wno-pointer-sign option used now (thus enabling -Wpointer-sign warnings). That change would enable a warning that results from the mixing of pointers to signed and unsigned char types; Torvalds complained that it fails to warn when using char variables, but produces a lot of false positive warnings with correct code.