> Here's a _fact_: > > - we currently walk the device chain to suspend different devices > - one device returns an error > - we've now suspended half the machine, done major things, and we need to > undo it > - the thing fails. > > Are you seriously claiming this has never happened to you? It sure has > happened to me. It happens occasionally (latest was a USB controller going dead occasionally on a box and usb suspend() method for it failing when that happens). When we fail, we resume() things that were suspended(), at least we used to, and that works. That is suspending fails but at least the machine comes back into operational state and you can look at dmesg, console, whatever. I haven't had the case where _that_ failed. > And YES, THIS WOULD BE IMPROVED BY MY SCHEME. Instead of getting a machine > that has suspended partly, and may be effectively dead and unable to even > tell the user that it failed half-way through, it would not have suspended > anything at all, and just say "Sorry, I can't do that". That would have been fixed by a prepare() callback too as I'm advocating it. This has nothing to do with saving state. > Adn yes, this is a _direct_ result of THE BROKEN CONVENTION OF DOING > EVERYTHING IN SUSPEND()! > > But yeah, you go on and ignore it. Because the current scheme is obviously > all right. The current scheme is not perfect, and I've proposed at least one mecanism to improve it. My argument is that it has nothing about saving state and changing the state save vs. suspend semantics. Changing _that_ won't help. Ben.
