On Fri, 23 Jun 2006, David Brownell wrote: > > Seriously, suspend() tends to be less of a problem than resume(). Which > is why I'm lukewarm to notions of refactoring suspend(). Now, I obviously agree, I just don't see any good way to refactor resume at all. So I think we should attack the problems that we _can_ attack. Btw, I disagree violently with the standpoint that you and Pavel have had that we currently just do enough in "suspend()" to make STR work, and that gets STD working automatically. Several suspend() functions I've seen (networking in particular) do a _hell_ of a lot more than they need for STR, exactly because they try to protect against problems that happen with STD, but _not_ STR. Network devices tend to do things like "unregister from the network stack" etc, all of which should be totally unnecessary for STR. It's all there really for _disk_ suspend, to make things quiet. So the whole argument that "suspend()" is the minimal functionality is just totally bogus. Its' simply not _true_. The current suspend() functions do lots of things that have nothing to do with actual device suspend, exactly because the current setup forces them to do so, not because they would actually _need_ to do so for STR. Linus