(If you reply, please do so on linux-pm, to avoid forking in 2 different threads. I originally CC to lkml since people interested in this issue may for most of them not yet be subscribed to linux-pm). Ok, since we are close to agreeing on the suspend messages (and I think the way we are going now is simple & flexible enough to allow us to extend thing if we feel the need for it), here's another concern I have: Growing numbers of things in the kernel require call_usermodehelper(). This typically includes hotplug events and the request_firmware() interface. I'm even considering using that for a new mecanism of notifying userland of the whole suspend/resume process, but that's orthogonal to my point below: We can't afford to let userland be called once the sleep process has started. swap or other dependent devices may be gone, userland may be frozen (or not, again, I don't plan to freeze userland on ppc suspend to ram) but anyway, the point is, userland isn't there. There is another problem not related to PM directly but with similar consequences, which is that call_usermodehelper() nowadays tend to be called way to early during boot. We just had to work around a bug on ppc64 where somebody was trying to call /sbin/hotplug in the middle of arch_initcalls(), where the arch code was obviously not ready to start some userland process. The idea here is to add to the call_usermodehelper() API a plug/unplug semantic (like the BIO). When "plugged", usermodehelper calls would stack up, and would be issued in one shot when "unplugged". By default, at boot, we would be "plugged" until some time, either after the initcalls or at a given initcall level, that remains to be decided. During suspend/resume, we would plug/unplug as well, possibly directly from the PM core, just before starting the driver suspend/resume dance. The main problem here is: request_firmware(). Drivers tend to use that synchronous interface to request a firmware from userland. In our case, that mean they would deadlock (or timeout) and fail... There is an asynchronous version of request_firmware() that perfectly fits, however, it makes things slightly more complicated for drivers wanting to use it, so I suspect unless told to do so using brute force, drivers maintainers won't go that way. Which basically means deprecating request_firmware() in favor of request_firmware_nowait(). We aren't quite there yet, which is why I'm posting here instead of lkml at this point. I think we must first finish polishing our new callbacks and convert the tree, and on the other side of this, add the plug/unplug functionality to call_usermodehelper(). But once that's done, drivers calling request_firmware() (like my prism54) on wakeup from sleep or at boot with a populated initramfs will become a problem. Ben.
