> No reason there shouldn't be both. On the other hand, > keep in mind that the typical case with selective suspend > is going to be that usermode is there, and working just > fine ... if you're concerned with shutdown sequences > that need userspace to behave, one strategy would be > to quiesce more intelligently: shutting down as much > as possible *BEFORE* userspace can no longer assist. It's very difficult to predict. Any block device can be on the VM path for example, or a network driver can be in the way (NFS) etc... > And on resume, in_system_resume() would be true until > userspace is available again ... just one call needed? > > But I don't think any "quiesce the system" strategy > that works well on complex systems can be very simple. > > The firmware example is just one case from its > class ... quiescing (plus resuming) a component > that needs help both from kernel (driver, ...) and > userspace (firmware or other services). Single phase > "kernel only" quiesce models have obvious holes. > A two phase model is probably necessary, though > we don't have one. (I hope two is enough, but > that gets into larger design issues.) Yes, but the "need userspace" phase doesn't block device activity and doesn't need bus ordering, so can be a simple notifier list, very few drivers really need it. Though just using different PRE-SUSPEND and POST-RESUME messages & the existing callbacks would work too. Ben.
