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
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.
-
ZorinOS 17.1 Released, Includes Improved Windows App Support
If you need or desire to run Windows applications on Linux, there's one distribution intent on making that easier for you and its new release further improves that feature.
-
Linux Market Share Surpasses 4% for the First Time
Look out Windows and macOS, Linux is on the rise and has even topped ChromeOS to become the fourth most widely used OS around the globe.
-
KDE’s Plasma 6 Officially Available
KDE’s Plasma 6.0 "Megarelease" has happened, and it's brimming with new features, polish, and performance.
-
Latest Version of Tails Unleashed
Tails 6.0 is based on Debian 12 and includes GNOME 43.
-
KDE Announces New Slimbook V with Plenty of Power and KDE’s Plasma 6
If you're a fan of KDE Plasma, you'll be thrilled to hear they've announced a new Slimbook with an AMD CPU and the latest version of KDE Plasma desktop.
-
Monthly Sponsorship Includes Early Access to elementary OS 8
If you want to get a glimpse of what's in the pipeline for elementary OS 8, just set up a monthly sponsorship to help fund its continued existence.
-
DebConf24 to be Held in South Korea
Busan will be the location of the latest DebConf running July 28 through August 4