On Friday 23 June 2006 4:44 pm, Linus Torvalds wrote: > > We can't do that right now, but I think we can split up "->suspend()" the > other way: split the remains into two, similarly to how "save_state()" is > for "stuff that can be done without any side effects". We would have > "early suspend with interrupts enabled" and "late suspend with interrupts > disabled". That would certainly get rid of the bizarre disjunction that now exists for the "irqs enabled" and "irqs disabled" paths. Though it's unclear to me how many drivers would actually _use_ that second "irqs off" method. In terms of API migration, it would seem like the former should just be today's suspend() -- though other changes might follow, later on -- and the new method should be late_suspend() ... maybe without that annoying pm_message_t/PM_EVENT_* parameter. > This, btw, is something we can (and probably should) do on the resume side > too. Again, "early_resume()" would be done before interrupts are enabled > and other cores are brought up. And "late_resume()" would be done with > interrupts on. > > (And I think Ben is right, we might want to have a "final_resume()" which > is called when user mode has resumed). All those seem like plausible API changes, though it's not clear to me what drivers would need them ... or the overall benefit. > I really don't understand people who think that one routine is better than > five routines. Complete and implementable proposals (not necessarily patches) seem to have been lacking. I've seen "refactor one into five" type changes that have been wins ... and ones that have been huge loses. - Dave > I pretty much _guarantee_ that most devices will still just > have one or two routines, but they'll be simpler, just because they can be > more directed rather than flailing around wildly and aimlessly because of > having just one interface that needs to make everybody happy. > > Five simple routines are _superior_ to one complicated routine. That is > true even if the five simple routines end up having more lines of code. > > Linus >
