Linux Kernel and Graphics News
-
Next magic Linux program to will change the world? Io_uring • The Register
A few years ago developers knew eBPF as a handy way to build firewalls yet now it's used everywhere for everything. Get ready for io_uring to do the same.
Most people don't know the first thing about Linux programming. Why should they? Linux, more so than most operating systems, just works. But under the surface, there are programs such as eBPF that are transforming the infrastructure under the operating system we use every day.
As revealed this week, Microsoft chose to port eBPF into Windows rather than try to duplicate its functionality with its own program. io_uring may become the next Swiss-Army tool for Linux developers.
Io_uring allows Linux to launch an operation asynchronously and wait for its completion. Unlike its asynchronous I/O (AIO) subsystem, its predecessor, io_uring uses a memory ring buffer shared between user space and the Linux kernel. This enables it to submit operations and collect the results without needing time-expensive Linux kernel calls. Its API is complex, but if your applications require lots of I/O, you get rewarded with vastly improved increased performance.
-
Rust is coming to the Linux kernel • The Register
Both Linus Torvalds' Open Source Summit keynote and Jonathan Corbet's "Kernel Report" discussed efforts to allow Rust modules in Linux.
The next version of the kernel will be 6.0, but as ever, the change of major version number doesn't denote any major technical changes. Torvalds acknowledged that it might have been desirable to have a headline feature such as "now you can develop drivers in Rust," but this probably won't happen until kernel 6.1.
So far, there is a working group, and a preliminary patch has been submitted. There are also two preliminary drivers implemented in the new language, which are discussed in depth over on LWN: a driver for NVMe drives, and an in-kernel server for the 9P network protocol from the Plan 9 operating system.
-
Dave Airlie (blogspot): LPC 2022 Accelerators BOF outcomes summary
At Linux Plumbers Conference 2022, we held a BoF session around accelerators.
This is a summary made from memory and notes taken by John Hubbard.
We started with defining categories of accelerator devices.
1. single shot data processors, submit one off jobs to a device. (simpler image processors)
2. single-user, single task offload devices (ML training devices)
3. multi-app devices (GPU, ML/inference execution engines)
One of the main points made is that common device frameworks are normally about targeting a common userspace (e.g. mesa for GPUs). Since a common userspace doesn't exist for accelerators, this presents a problem of what sort of common things can be targetted. Discussion about tensorflow, pytorch as being the userspace, but also camera image processing and OpenCL. OpenXLA was also named as a userspace API that might be of interest to use as a target for implementations.
-
Dave Airlie (blogspot): LPC 2022 GPU BOF (user console and cgroups)
Currently most mainline distros still use the kernel console, provided by the VT subsystem. We'd like to move to CONFIG_VT=n as the console and vt subsystem have historically been a source of bugs but are also nasty places for locking etc. It also can be the cause of oops going missing when it takes out the panic path with locking bugs stopping other paths from completely processing the oops (like pstore or serial).
The session started discussing what things would like. Lennart gave a great summary of the work David did a few years ago and the train of thought involved.
Once you think through all the paths and things you want supported, you realise the best user console is going to be one that supports emojis and non-Latin scripts. This probably means you want a lightweight wayland compositor running a fullscreen VTE based terminal. Working back from the consequences of this means you probably aren't going to want this in systemd, and it should be a separate development.
The other area discussed was around the requirements for a panic/emergency kernel console, likely called drmlog, this would just be something to output to the display whenever the kernel panics or during boot before the user console is loaded.
-
Mike Blumenkrantz: Meatballs
Let’s talk about Intel.
I know what you’re thinking.
If you work for Intel, you’re thinking Oh no.
If you don’t, you’re thinking Oh no. Or possibly getting ready to post some comments about ANV not supporting features, or having bugs, or any of the common refrains that I’ve seen so often around the internet.
The fact remains, however, that ANV is the reference zink hardware driver. It has been ever since I started working on zink. The reason for this is simple: it’s what I have on the machine I develop with, and when I started working on zink, it was the driver that was furthest along.
It’s therefore no exaggeration to say that without everything ANV and the Intel Mesa team brings to the table, zink wouldn’t be nearly as far along as it is.