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.

comments powered by Disqus

Direct Download

Read full article as PDF:

066-067_kernel.pdf (829.72 kB)

News