Zack's Kernel News
Driver Dependencies
Rafael J. Wysocki wanted to create a new set of dependencies associated with the Linux kernel: specifically, the dependency that one device and its associated driver might have for another. His idea was that a device and its driver would register a dependency on another device and driver, thus linking them together logically. This way, an attempt by the user to unload a driver that was needed by another device could be forestalled by the system. The driver in question could only be unloaded after all other drivers released their links to it.
Tomeu Vizoso thought this would be a great idea, as long as the dependencies could be figured out properly. In particular, Rafael wanted to distinguish between two types of dependency links between drivers: those that were created when the device was registered with the system and those that only came into being when the device probed the system to see what other hardware was available. Tomeu felt there was a strong danger of code duplication in the latter case between the probing code and the linking code. Also, he felt that if the kernel couldn't be refactored to avoid that duplication, it would be a tough problem to keep both sets of code in sync with each other.
Rafael replied, "That almost certainly is going to be a fair amount of work, but that doesn't mean we should avoid doing it. If it leads to better code eventually, it's worth doing."
Tomeu was also concerned that Rafael wanted to make things too complicated by having drivers construct dependency links before probing the system based on whatever information was already available. He thought it would be easier simply to do the probe. Rafael replied that it would be easier to understand the order of operations if the system used information that was already available, although he acknowledged that if it proved very difficult to collect that information, it wouldn't be worth it.
Meanwhile, Linus Walleij said he liked Rafael's proposal very much, although he also pointed out that circular dependencies could become a problem.
Greg Kroah-Hartman also liked Rafael's plan and thought that Rafael had also successfully identified the implementation requirements.
Thierry Reding was also very supportive. He said, "I think this would be a huge step towards making the kernel more robust with little driver or subsystem code having to be duplicated. Currently most provider/consumer subsystems are fragile in that there isn't proper reference counting. Many subsystems will happily allow you to remove any of the provider, regardless of whether or not it has consumers. Most of the subsystems will make sure that modules can't be unloaded, but beyond that won't be able to prevent drivers from being unbound (either when a device is unplugged or unbound via sysfs). Even with proper reference counting there is no easy way to deal with devices going away (you'd need some sort of revoke semantics implemented for all providers, and consumers must be able to handle that situation gracefully)."
Thierry added, "I can also imagine subsystems where a reliable mechanism is in place to properly hotplug and -unplug providers. The good thing about the functional dependencies mechanism you propose here is that it's an optional mechanism that drivers use from ->probe()
. Subsystems where a better mechanism exists can simply choose to do without functional dependencies."
Elsewhere, Andrzej Hajda pointed out an issue he had with Rafael's idea: He felt that certain drivers should be able to have "weak" dependencies, where the driver could still function in a limited capacity even if some of its dependencies weren't met, although later he acknowledged that, "It should be enough if provider notifies consumers that the resource will be unavailable."
There were various technical questions and comments, mostly having to do with exactly how and when drivers might communicate their dependencies to each other. Eventually Rafael posted some actual code to implement what he was talking about, and the conversation petered out.
It seems as though, in general, nobody objects to drivers having these sorts of dynamic and enforced dependencies. The issues seem to be code duplication and the need to keep specific behaviors sane and usable. It seems as though once the code gets a bit further along, it will sail into the main source tree.
Speeding Up the Balloons
Liang Li wanted to improve the speed at which the VirtIO balloon driver could inflate and deflate. A balloon driver is one technique of allowing a virtual Linux system to gain access to more memory. To the virtual system, the driver gives the appearance of using a lot of memory, while in fact the memory isn't used at all and is simply available to the host to use for other processes. When the virtual system needs access to more memory, the balloon driver seems to "free up" some of the memory it has allocated. In fact, the newly available memory is being allocated by the host. It's all just a blue pill to let the virtual system think it's not plugged into a Matrix feeding pod.
However, the act of maintaining that illusion is slow, at least according to Liang. To inflate the balloon to 3G on a virtual system that believed itself to have 4G available took about 1.5 seconds on Liang's setup. He posted a patch to reduce this to a ninth of the speed, down to 175 milliseconds. The key, he said, was to avoid passing heavyweight page frame numbers around and to use a sleek bitmap instead.
Cornelia Huck had some technical suggestions, and Michael S. Tsirkin felt that Liang's implementation had some race conditions that needed to be ironed out. After some back and forth, Liang posted another patch that addressed Michael's races, but at a speed cost. The new code took 338 milliseconds instead of 175. This didn't seem like a necessary cost to Michael, and the two of them went back and forth on it. Michael also submitted his own versions of the patch to illustrate some of his implementation ideas.
At some point the discussion petered out. Clearly, though, even at 338 milliseconds, Liang's patch is a big improvement over the existing code. With modern corporations running vast farms of virtualized systems, this kind of speedup makes a big difference.
Zack Brown
The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown.
« 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
-
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.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.