Oleksij Rempel of Pengutronix Embedded Linux Consulting released a series of patches on Friday proposing priority-based shutdown support for drivers/hardware.
The main purpose is to provide the function of preferentially shutting down specific devices in the mainline Linux kernel . "This is especially important in situations such as power loss, which may cause hardware damage if not handled properly."
The focus is on properly shutting down critical equipment during unexpected/ immediate shutdown events such as power/voltage drops or complete power outages. As part of the patch series, Oleksij Rempel also proposed setting (e)MMC storage devices to a higher priority during the shutdown phase to help ensure data integrity/corruption.
Oleksij Rempel's idea sparked heated discussions among Linux kernel developers and polarized opinions. Greg Kroah-Hartman first questioned this priority-based shutdown support. He pointed out that this approach can lead to priority competition between drivers and subsystems:
Every driver and subsystem insists that it is the most important!
In short, in the long run, this will cause a lot of problems. What is so special about this hardware that it cannot be shut down in the existing order, but must be "prioritized" before others? What exactly does this prevent, and which devices need to do this?
Most importantly, what has changed in the last 20+ years that would suddenly require this new functionality, and how do other operating systems handle it?
There has been much discussion on both sides of the argument as to whether the mainline Linux kernel should have such a feature to effectively address problematic hardware designs. It turns out that some outer Linux kernel versions used in the automotive industry already provide this preferential shutdown support. Oleksij Rempel summarizes this need as:
It prevents hardware damage. In a typical automotive undervoltage test, you can usually reproduce X number of damaged eMMCs or NANDs in Y undervoltage cycles (I don't have the exact number right now). Even if the numbers that show up in manual testing aren't that high (sometimes one broken device shows up in a month of testing), the return on the field is high enough for us to care about a software solution to this problem.
The same problem occurs not only with automotive equipment, but also with industrial or agricultural equipment. In other words, the problem is important enough that there must be some kind of solution.
In response, Greg joked in a rhetorical tone, "So, hardware is trying to rely on software to prevent the same hardware from being destroyed? Hardware designers are certainly not that crazy, right?"
Technology website Phoronix commented that at a high level, if the device/driver has a good reason to want to prepare for device shutdown first, such as to prevent data loss or gain other significant advantages, then this kind of priority-based shutdown There seems to be no issues with support. In practice, however, implementation difficulties can arise if there are multiple drivers claiming "priority" during the shutdown process, and if there are other obstacles to ensuring that the design is reliable and properly solves the actual problem.
So far, opinions on this approach are far from unanimous. It remains to be seen whether a suitable solution can be devised at this stage that is both acceptable to the mainline and meets the needs of the automotive and wider embedded/industrial sectors.