Linux Kernel Developers Debate Priority-Based Shutdown Support
A Linux kernel mailing list discussion this holiday weekend that is seeing polarized views on the matter is around a new patch series proposed priority-based shutdown support for drivers/hardware.
Oleksij Rempel with the Pengutronix embedded Linux consulting firm sent out a patch series on Friday for adding priority-based shutdown support. The focus is on providing the ability within the mainline Linux kernel to prioritize shutting down specific devices first, such as in cases of power loss. This priority-based shutdown support appears motivated by the automotive Linux industry where a software solution like this is "crucial in scenarios like power loss where hardware damage can occur if not handled properly."
With the patch series this prioritized device shutdown support was focused on properly shutting down critical devices during unexpected/immediate shutdown events like power/voltage drops or complete power off. As part of the patch series is also setting (e)MMC storage devices at a higher priority during the shutdown phase for helping ensure data integrity / corruption.
While at a high level this priority-based shutdown support appears fine if there's good reason for a device/driver to want to prepare a device for powering off first, such as if it would prevent data loss or otherwise significant advantage. But in practice it's harder to pull off when there could be multiple drivers claiming "priority" in the shutdown process and other obstacles in ensuring it's a solid design and will properly solve a real problem.
Greg Kroah-Hartman was quick to question this priority-based shutdown support. Greg initially commented:
There's been many replies since on both sides and whether the mainline Linux kernel should have such functionality to effectively workaround questionable hardware designs. It turns out some out-of-tree Linux kernel versions for the automotive industry already carry such priority shutdown support. The need was summed up by Oleksij Rempel as:
Greg later quipped, "So hardware is attempting to rely on software in order to prevent the destruction of that same hardware? Surely hardware designers aren't that crazy, right? (rhetorical question, I know...)"
It was also raised why such functionality couldn't be implemented in user-space, among other ideas. Those interested in some fun Linux kernel mailing list weekend reading can see this kernel mailing list thread. So far there's very differing opinions on this approach and it remains to be seen at this stage whether an appropriate solution can be devised that is acceptable for mainline while fitting the needs of the automotive and more broadly the embedded/industrial space.
Oleksij Rempel with the Pengutronix embedded Linux consulting firm sent out a patch series on Friday for adding priority-based shutdown support. The focus is on providing the ability within the mainline Linux kernel to prioritize shutting down specific devices first, such as in cases of power loss. This priority-based shutdown support appears motivated by the automotive Linux industry where a software solution like this is "crucial in scenarios like power loss where hardware damage can occur if not handled properly."
With the patch series this prioritized device shutdown support was focused on properly shutting down critical devices during unexpected/immediate shutdown events like power/voltage drops or complete power off. As part of the patch series is also setting (e)MMC storage devices at a higher priority during the shutdown phase for helping ensure data integrity / corruption.
While at a high level this priority-based shutdown support appears fine if there's good reason for a device/driver to want to prepare a device for powering off first, such as if it would prevent data loss or otherwise significant advantage. But in practice it's harder to pull off when there could be multiple drivers claiming "priority" in the shutdown process and other obstacles in ensuring it's a solid design and will properly solve a real problem.
Greg Kroah-Hartman was quick to question this priority-based shutdown support. Greg initially commented:
"Oh fun, now we will have drivers and subsystems fighting over their priority, with each one insisting that they are the most important!
/s
Anyway, this is ripe for problems and issues in the long-run, what is so special about this hardware that it can not just shutdown in the existing order that it has to be "first" over everyone else? What exactly does this prevent and what devices are requiring this?
And most importantly, what has changed in the past 20+ years to suddenly require this new functionality and how does any other operating system handle it?"
There's been many replies since on both sides and whether the mainline Linux kernel should have such functionality to effectively workaround questionable hardware designs. It turns out some out-of-tree Linux kernel versions for the automotive industry already carry such priority shutdown support. The need was summed up by Oleksij Rempel as:
"It prevents HW damage. In a typical automotive under-voltage labor it is usually possible to reproduce X amount of bricked eMMCs or NANDs on Y amount of under-voltage cycles (I do not have exact numbers right now). Even if the numbers not so high in the labor tests (sometimes something like one bricked device in a month of tests), the field returns are significant enough to care about software solution for this problem.
Same problem was seen not only in automotive devices, but also in industrial or agricultural. With other words, it is important enough to bring some kind of solution mainline."
Greg later quipped, "So hardware is attempting to rely on software in order to prevent the destruction of that same hardware? Surely hardware designers aren't that crazy, right? (rhetorical question, I know...)"
It was also raised why such functionality couldn't be implemented in user-space, among other ideas. Those interested in some fun Linux kernel mailing list weekend reading can see this kernel mailing list thread. So far there's very differing opinions on this approach and it remains to be seen at this stage whether an appropriate solution can be devised that is acceptable for mainline while fitting the needs of the automotive and more broadly the embedded/industrial space.
59 Comments