On Tuesday, 3 July 2007 13:46, Oliver Neukum wrote: > Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > > On Tue, 2007-07-03 at 09:44 +0200, Oliver Neukum wrote: > > > Am Dienstag, 3. Juli 2007 schrieb Benjamin Herrenschmidt: > > > > So to summarize, the plan that makes things work with fuse is: > > > > > > > > - For STR, don't do the freezer thing. > > > > > > > > - For STD, don't sys_sync() after you froze > > > > > > > > There might be -other- issues, but that should get you through some of > > > > > > At the risk of repeating myself. Character device drivers are written > > > with the assumption that normal io and suspend/resume do not race > > > with each other due to the freezer. > > > What do you intend to do about that? > > > > Ugh ... "character devices" ... that's a pretty wide statement... > > there's lots of those and very different one from the other... > > That is a good summary of the problem ;-( > > > Any sane device-driver will have to cope with being suspended in a > > "live" system. I've demonstrated multiple times in the past why this is > > necessary anyway, for things like dynamic power management, among > > others. > > That is an interesting notion. I'd rather see device drivers reporting > their devices idle and requsting to be suspended. > But in any case it doesn't solve the problem. Agreed. What I think will solve the problem in the long run is to: 1) Separate the hibernation code from the suspend code (ie. hibernation-related callbacks should generally be different from suspend-related callback for each driver). 2) Remove the freezing of kernel threads from each of them (in the hibernation case, if possible) an fix the things that get broken. 3) Remove the freezing of user space from the suspend code path and fix the things that get broken. Going to step 3) before doing 1) and 2) doesn't seem to be the right thing to me. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
