Zack's Kernel News
Driver Coding Pitfalls
Atul Mukker from LSI Corp. announced their intention to initiate a new approach to LSI RAID controller driver creation. They want to keep the code generic across multiple operating systems, keeping only small Linux-specific, Mac-specific, and so on, sets of surface code to access the core driver. He asked for any advice the Linux kernel community wanted to give him.
Jeff Garzik agreed that this could be a great benefit to everybody, if done right. But he did feel that certain mistakes had been made in the past, that they would be best not to repeat. He said, "in the past, when hardware vendors have created a cross-OS layer for their drivers, that layer wound up decreasing performance, increasing code size, introducing bugs, and decreasing overall portability." He pointed to Intel's network drivers as an example of a similar effort that had avoided the worst pitfalls. Atul was heartened by this reply because it seemed that it was indeed possible to do what he'd envisioned. He asked for further suggestions, and Jeff obliged. Jeff suggested making the code modular, to keep code supporting specific hardware separate from each other and separate from the OS-specific code. This might not be a simple thing to do, Jeff said; in fact, he considered it a first-class engineering task. As a general admonition, he recommended avoiding too many C pre-processor wrappers and recommended making good use of C's native types and enums.
Jeff also recommended that any code that could be generalized and made non-specific to LSI's drivers should be kept out of the driver, so it could more easily be shared by other projects. Jeff said that the driver's ABI (Application Binary Interface) should be consistent with other Linux drivers. Features not unique to LSI but similar to features found in other drivers should try to behave the way those other drivers behaved. Features unique to LSI, Jeff said, were fair game for LSI to handle however it wanted. Jeff concluded that Linux contributors had to consider LSI's code within the context of code submitted from other hardware vendors, including LSI's direct competitors. This was primarily to avoid code duplication, but also because multiple implementations of the same features would multiply the potential bugs. The Linux maintainers also had to consider the future case in which hardware would no longer have vendor support, but users would still rely on the Linux drivers. Atul thanked everyone for helping them get started with this project.
Event Configuration In DebugFS
Steven Rostedt announced enhancements to event tracing in DebugFS. Enabling events one at a time can be tedious, and even enabling them in groups requires too much detail. Steven wanted to be able to enable all tracing events below a given directory in DebugFS, so his patch created a new file in each directory called enable. A value of 1 in such a file will enable all events defined in that directory and all subdirectories. A value of 0 will disable the same set of events. But he didn't stop there! To prune the directory tree selectively, you can put a 1 in the enable file of a given directory and then a 0 in that of any subdirectory to be excluded. So, with a minimum of effort, swaths of events can be enabled and excluded, without the bother of naming them all. Frederic Weisbecker loved this patch, but Li Zefan objected, saying Steven's implementation made it difficult to figure out which events were enabled. He said that he'd normally expect to get a list of enabled events by viewing the config file, but in Steven's patch, the config file would mysteriously contain only a 1 or 0. Steven's response was that the patch had taken him 15 minutes to code, claiming the benefit of simplicity, and that it was tailored for the person setting the events rather than anyone interested in reading them. Because the configuration files referred to a hierarchically organized directory tree, all the information was still available and could be retrieved by a script. Li replied that he had no serious objection to this, but had brought it up in case anyone else wanted to take issue with it. Apparently, no one did.
« Previous 1 2
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Red Hat Adds New Deployment Option for Enterprise Linux Platforms
Red Hat has re-imagined enterprise Linux for an AI future with Image Mode.
-
OSJH and LPI Release 2024 Open Source Pros Job Survey Results
See what open source professionals look for in a new role.
-
Proton 9.0-1 Released to Improve Gaming with Steam
The latest release of Proton 9 adds several improvements and fixes an issue that has been problematic for Linux users.
-
So Long Neofetch and Thanks for the Info
Today is a day that every Linux user who enjoys bragging about their system(s) will mourn, as Neofetch has come to an end.
-
Ubuntu 24.04 Comes with a “Flaw"
If you're thinking you might want to upgrade from your current Ubuntu release to the latest, there's something you might want to consider before doing so.
-
Canonical Releases Ubuntu 24.04
After a brief pause because of the XZ vulnerability, Ubuntu 24.04 is now available for install.
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.