BCacheFS Is Now A DKMS Module After Exile From The Linux Kernel

It’s been a tense few months for users of the BCacheFS filesystem, as amidst the occasional terse arguments and flowery self-praise on the Linux Kernel mailing list the future of this filesystem within the Linux kernel hung very much in the balance. After some initial confusion about what ‘externally maintained’ means in Linux parlance, it’s now clear that this means that BCacheFS has effectively been kicked out of the kernel as [Linus] promised and will ship as a DKMS module instead. The gory details of this change are discussed in a recent video by [Brodie Robertson].

We covered the BCacheFS controversy in the Linux world a few months ago, amidst reports of data loss and filesystem corruption among its users. Its lead developer, [Kent Overstreet], came to blows with [Linus Torvalds] on the LKML after [Kent] insisted on repeatedly pushing new features into kernel release candidate branches along with rather haughty statements on why he should be able to do this.

To make a long story short, [Linus] didn’t like this and froze BCacheFS support in the current kernel release with all future in-kernel development ceased. Distributions like SuSE have initially said that will disable BCacheFS starting in kernel version 6.17, meaning that users of BCacheFS may now have to install the DKMS module themselves. Some distributions like Arch are likely to include this DKMS module by default, which is something you want to check if you use this filesystem.

Continue reading “BCacheFS Is Now A DKMS Module After Exile From The Linux Kernel”

What Does Linux Need? A Dial!

It’s fair to say that there can’t be many developers who have found the need for a rotary telephone dial as a peripheral for their Linux computer, but in case you are among them you might find [Stefan Wiehler]’s kernel driver for rotary dials to be of use.

It’s aimed at platforms such as systems-on-chip that have ready access to extra GPIOs, of which it will need a couple to service the BUSY and PULSE lines. There are full set-up instructions, and once it’s in place and configured it presents the dial as though it were a number pad.

We like this project, in fact we like it a lot. Interfacing with a dial is always something we’ve done with a microcontroller though, so it will be interesting to see whether it finds a use beyond merely curiosity. We can already see a generation of old-school dial IP phones using Linux-capable dev boards. He leaves us with a brief not as to whether Linus Torvalds would see it as worthy of mainline inclusion, and sadly however much we want things to be different, we agree that it might be wishful thinking.

If you’d like to use a dial phone, there can be simpler ways to do it.

Header: Billy Brown, CC BY 2.0 .

Tracing The #!: How The Linux Kernel Handles The Shebang

One of the delights in Bash, zsh, or whichever shell tickles your fancy in your OSS distribution of choice, is the ease of which you can use scripts. These can be shell scripts, or use the Perl, Python or another interpreter, as defined by the shebang (#!) at the beginning of the script. This signature is followed by the path to the interpreter, which can be /bin/sh for maximum compatibility across OSes, but how does this actually work? As [Bruno Croci] found while digging into this question, it is not the shell that interprets the shebang, but the kernel.

It’s easy enough to find out the basic execution sequence using strace after you run an executable shell script with said shebang in place. The first point is in execve, a syscall that gets one straight into the Linux kernel (fs/exec.c). Here the ‘binary program’ is analyzed for its executable format, which for the shell script gets us to binfmt_script.c. Incidentally the binfmt_misc.c source file provides an interesting detour as it concerns magic byte sequences to do something similar as a shebang.

As a bonus [Bruno] also digs into the difference between executing a script with shebang or running it in a shell (e.g. sh script.sh), before wrapping up with a look at where the execute permission on a shebang-ed shell script is checked.

This Week In Security: The Geopolitical Kernel, Roundcube, And The Archive

Leading off the week is the controversy around the Linux kernel and an unexpected change in maintainership. The exact change was that over a dozen developers with ties to or employment by Russian entities were removed as maintainers. The unfortunate thing about this patch was that it was merged without any discussion or real explanation, other than being “due to various compliance requirements”. We eventually got more answers, that this was due to US sanctions against certain Russian businesses, and that the Linux Foundation lawyers gave guidance that:

If your company is on the U.S. OFAC SDN lists, subject to an OFAC sanctions program, or owned/controlled by a company on the list, our ability to collaborate with you will be subject to restrictions, and you cannot be in the MAINTAINERS file.

So that’s that. One might observe that it’s unfortunate that a single government has that much control over the kernel’s development process. There were some questions about why Russian entities were targeted and not sanctioned Chinese companies like Huawei. [Ted Ts’o] spoke to that, explaining that in the US there are exemptions and different rules for each country and business. This was all fairly standard compliance stuff, up until a very surprising statement from [James Bottomley], a very core Kernel maintainer:

We are hoping that this action alone will be sufficient to satisfy the US Treasury department in charge of sanctions and we won’t also have to remove any existing patches.

Continue reading “This Week In Security: The Geopolitical Kernel, Roundcube, And The Archive”

The Usage Of Embedded Linux In Spacecraft

As the first part of a series, [George Emad] takes us through a few examples of the Linux operating system being used in spacecraft. These range from SpaceX’s Dragon capsule to everyone’s favorite Martian helicopter. An interesting aspect is that the freshest Linux kernel isn’t necessarily onboard, as stability is far more important than having the latest whizzbang features. This is why SpaceX uses Linux kernel 3.2 (with real-time patches) on the primary flight computers of both Dragon and its rockets (Falcon 9 and Starship).

SpaceX’s flight computers use the typical triple redundancy setup, with three independent dual-core processors running the exact same calculations and a different Linux instance on each of its cores, and the result being compared afterwards. If any result doesn’t match that of the others, it is dropped. This approach also allows SpaceX to use fairly off-the-shelf (OTS) x86 computing hardware, with the flight software written in C++.

NASA’s efforts are similar, with Ingenuity in particular heavily using OTS parts, along with NASA’s open source, C++-based F’ (F Prime) framework. The chopper also uses some version of the Linux kernel on a Snapdragon 801 SoC, which as we have seen over the past 72 flights works very well.

Which is not to say using Linux is a no-brainer when it comes to use in avionics and similar critical applications. There is a lot of code in the monolithic Linux kernel that requires you to customize it for a specific task, especially if it’s on a resource-constrained platform. Linux isn’t particularly good at hard real-time applications either, but using it does provide access to a wealth of software and documentation — something that needs to be weighed up against the project’s needs.

A colorful diagram representing the inner structure of the Linux kernel.

Find That Obscure Function With This Interactive Map Of The Linux Kernel

Linux has become one of the largest operating systems on the servers that run large websites, and hopefully, one day, it will be big in the desktop market too. Some of you may know how Linux as an operating system is structured, but have you ever wondered how the kernel itself is structured? Maybe you’ll find this colorful interactive map of the Linux kernel by [Costa Shulyupin] useful.

The interactive map depicts the major levels of abstraction and functionalities, dotted with over 400 prominent functions from the Linux kernel, which are also links to a cross-reference site so you can see all the definitions and usages. It divides the kernel into 7 rows and 7 columns containing domains with well-known terms like security and debugging, but also more obscure things like block devices and address families. These are also links, this time to the definition of the term in question. Finally, there are arrows flying everywhere, to show the relationships between all the many functions in the kernel.
Continue reading “Find That Obscure Function With This Interactive Map Of The Linux Kernel”

A Power Button For Raspberry Pi, Courtesy Of Device Tree Overlays

As a standard feature of the Linux kernel, device tree overlays (DTOs) allow for easy enabling and configuration of features and drivers, such as those contained within the standard firmware of a Raspberry Pi system. Using these DTOs it’s trivial to set up features like as a soft power-off button, triggering an external power supply and enable drivers for everything from an external real-time clock (RTC) to various displays, sensors and audio devices, all without modifying the operating system or using custom scripts.

It’s also possible to add your own DTOs to create a custom overlay that combines multiple DTO commands into a single one, or create a custom device tree binary (DTB) for the target hardware. Essentially this DTB is loaded by the Linux kernel on boot to let it know which devices are connected and their configuration settings, very similar to what the BIOS component with x86-based architectures handles automatically.

Ultimately, the DTB concept and the use of overlays allow for easy configuration of such optional devices and GPIO pin settings, especially when made configurable through a simple text file as on the Raspberry Pi SBC platform.

Continue reading “A Power Button For Raspberry Pi, Courtesy Of Device Tree Overlays”