Kernel: Rust, Maestro, and Linux

posted by Roy Schestowitz on Jan 04, 2024

• Maestro - Introduction [Ed: So maybe Linux [sic] Foundation can get behind it to get rid of Linux, just like with Zephyr]

  Maestro is a Unix-like kernel and operating system written from scratch in Rust

  Thanks to the internet, I can learn how most things I am interested in work. However, something stayed a mystery to me for a long time: computers.

  Computers are amongst the most complex tools that humanity has ever built. They are a marvel of engineering that we take for granted because we use them in our everyday lives.

  I like to dig into complexity, and I like to learn by doing. On top of that, I spend a lot of time on the computer. Wouldn’t it be cool if I had a system that I would know from A to Z and that I could customise as much as I wanted to fit my expectations?

• LWN ☛ Lenôtre: Maestro - Introduction

  On his blog, Luc Lenôtre introduces Maestro, ""a Unix-like kernel and operating system written from scratch in Rust"". Maestro is intended to be ""lightweight and compatible-enough with Linux to be usable in everyday life"". The project began, in C, back in 2018, but switched over to Rust after a year-and-a-half.

• LWN ☛ Progress toward a GCC-based Rust compiler

  The gccrs project is an ambitious effort started in 2014 to implement a Rust compiler within The GNU Compiler Collection (GCC). Even though the task is far from complete, progress has been made since LWN's previous coverage, according to reports from the project. Meanwhile, another hybrid and more mature approach to GCC Rust code generation is available in rustc_codegen_gcc.

  In 2022, the goal of gccrs was to be included in the GCC 13 release, but this expectation has not been met. The team is currently aiming for inclusion in GCC 14 (likely to be released by mid-2024), judging from its November 2023 monthly report.

• LWN ☛ Looking back at 2023

  Yet another year has come to an end. Much to our dismay, 2023 did not, in fact, happen exactly as we predicted back in January. So it seems that, once again, we will have to go through the process of looking at the predictions that we made and mocking each in turn, before getting into what was missed altogether. A lot happened in 2023, not all of which was predictable.

  Our first prediction was that the community would see a spike in AI-generated material submitted as contributions. If that has indeed happened, the quality has been high enough that those submissions have not been identified as coming from machine-learning applications. That is perhaps surprising, given the common reports that large numbers of developers are working with machine-learning assistance at this point. Be that as it may, it seems fair to say that the flood we predicted has not, as yet, arrived.

  [...]

  The prediction that new kernel functionality would be written in Rust and proposed for inclusion was reasonably obvious a year ago. Much of what has actually been proposed to go upstream is a reimplementation of existing functionality (the Rust Binder implementation, for example), which doesn't quite satisfy the prediction. Other work, though, such as PuzzleFS and the Apple M1 graphics driver, definitely does. As of this writing, a network PHY driver written in Rust, along with some supporting abstractions, is staged to be merged into 6.8, presumably shortly after the new year. As was predicted, no user-visible functionality written in Rust was actually merged in 2023. [...] Free software remains strong, in that much of the technology industry (and beyond) relies heavily upon it; as a result, there is more software being written and released than ever. It is still true, though, that many of the problems we have seen over the years — failure to live up to licensing requirements, unwillingness to support developers and maintainers, communities that do not feel welcoming to all, etc. — remain with us, and are not necessarily getting better. It is not surprising that people get discouraged and drop out, or never settle into our community in the first place.

• LWN ☛ Ext4 data corruption hits the stable kernels

  The kernel's stable-update process is intended to produce kernels that are, well, stable; when that promise is lived up to, users can update to newer stable updates without fear. By any account, a bug that corrupts data on ext4 filesystems constitutes a failure to hold to that promise. As is so often the case, this problem is the result of a chain of failures in a system that works well most of the time.

  For many people, the first notice of this problem came in the form of this Debian bug report stating that the 6.1.64 kernel, which had been rolled into the planned Debian 12.3 release, was exhibiting data-corruption problems. Debian developers quickly put that release on hold while investigating the problem, which was good as far as it went, but many Debian users update their systems often rather than waiting for the point releases. They may have gotten buggy kernels as a result. The bug is likely to have hit users of other fast-moving distributions and those who install their own kernels as well.

• LWN ☛ The intersection of mlx5, netdev, and lockdown

  The NVIDIA Mellanox ConnectX HW family of adapters is a complex beast, supporting networking, InfiniBand, RDMA, and more. As a result, the mlx5 kernel driver that supports this hardware is also complex, as is the interface that it provides to user space. The mlx5 developers have, for a while now, been proposing the addition of a new control interface, in the form of a separate virtual device exported by the kernel, that would make vast amounts of debugging information available. This driver has encountered some significant opposition on its way toward the mainline, though, raising a number of questions about appropriate interfaces and when subsystem maintainers have veto power over submissions.

  As described in the cover letter to the patch series, the hardware in question presents a sort of remote-procedure-call interface to the system; that interface is used to control a complex set of operations provided by the device. As developer Saeed Mahameed later said, the device ""is able to expose millions of objects and device states interactively""; that results in ""a complex debugging environment"" where it can be hard to figure out why something is not working correctly. That presents a challenge for both customers and Mellanox support personnel, all of whom need a way to get at information about the state of the device.

• LWN ☛ The Linux graphics stack in a nutshell, part 1

  Linux graphics developers often speak of modern Linux graphics when they refer to a number of individual software components and how they interact with each other. Among other things, it's a mix of kernel-managed display resources, Wayland for compositing, accelerated 3D rendering, and decidedly not X11. In a two-part series, we will take a fast-paced journey through the graphics code to see how it converts application data to pixel data and displays it on the screen. In this installment, we look at application rendering, Mesa internals, and the necessary kernel features.