On Monday, 28 May 2007 15:12, Pavel Machek wrote: > Hi! > > > Make it possible to register hibernation and suspend notifiers, so that > > subsystems can perform hibernation-related or suspend-related operations > > that > > should not be carried out by device drivers' .suspend() and > > .resume() routines. > > I believe it adds _way_ too many notifiers. > > > +PM_PRE_FREEZE The system is going to hibernate or suspend, > > tasks will > > + be frozen immediately > > 80 columns.
OK > Anyway yes, this one is needed. > > > +PM_POST_THAW Tasks have just been thawed after a resume or > > restore > > + from a hibernation image > > Symetrical with the previous one, useful for freeing firmware images, ok. > > > +PM_HIBERNATION_PREPARE The system is preparing for hibernation. Tasks > > have > > + been frozen, memory is going to be freed and devices > > + are going to be suspended. > > What is this one good for? Allocating memory before the hibernation, mainly. Anything done after freezing tasks. > > +PM_SNAPSHOT_FAILED The creation of hibernation image has failed. Tasks > > + will be thawed immediately. > > Does this one need to be different from POST_THAW? Do you mean POST_RESTORE? Well, maybe not. Yesterday I thought it would be for a specific reason, but now I can't recall what it was. :-( > I do not see the need for the other chains. Notice that we do not > _want_ to have too many of them, because changing anything in the > hibernation will become impossible with 10 chains having intimate > details of suspend sequence. I think the two suspend-specific might be handy. What about: PM_PRE_FREEZE PM_HIBERNATION_PREPARE PM_POST_HIBERNATION (handling failed snapshots too) PM_POST_THAW plus PM_RESTORE_PREPARE for the restore and PM_SUSPEND_PREPARE PM_POST_SUSPEND (handling failed suspends too) for the suspend code path? Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
