Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2:hang in atomic copy)
From: Linus Torvalds
Date: Wed Apr 25 2007 - 16:09:38 EST
On Wed, 25 Apr 2007, Kenneth Crudup wrote:
> Any working suspend-to-disk method takes care of that for me. (I'm
> really not sure why Linus hates S2D so much, though. Back in the day
> there was a lot more BIOS support, but that's been years now.)
The really sad part is that APM actually did this better..
It's not often you can say that, and APM didn't do diddly-squat for
run-time power management, but when it comes to suspend-to-disk, APM
actually did ok.
I think you could do STD right too, but:
- if you think it's about suspending devices, you are immediately
disqualified. If you call the device driver "suspend" or "resume"
functions, you are doing something wrong.
- "suspend" is: snapshot memory, and anything you do *after* the snapshot
is totally irrelevant. You MUST NOT suspend devices before, since
devices are what that snapshot should be written out to, and you MUST
NOT suspend devices afterwards either, because that shows that you are
a moron who didn't understand the "machine will be turned off" part.
- "resume" is basically: get image into memory, turn *off* every device,
put image into its proper location, and call the "startup" function. If
you call a device "resume()" function, you again show that you are a
moron, because you're not resuming anything at all, you're resetting
the device from scratch. You _reinitialize_ the device. You don't
resume it, and somebody may hve (and indeed, *WILL HAVE* used the
device in between). There should be absolutely zero shared code, and
the *last* thing you should do is to call the device with the same
function, and give it a flag to tell it to do one thing or the other.
The important thing to take away from this is that it has nothing to do
with "suspend" or "resume" at any level what-so-ever. Not at a device
level, not at a system level, and not even when it comes to hardware. But
for completely idiotic and wrong reasons, it is currently intimately
involved in suspend/resume, and calls the same device management functions
as a suspend/resume thing does, and shares a lot of the code.
And THAT is why I hate the kernel STD. It is fundamentally confused. In
ways that APM was not, I'd like to point out.
I'd love to get it fixed. But the first fix is to not call it "suspend",
because language *does* matter, and using that term is what I'm convinced
has confused so many people.
If it had been called "snapshot + restore", I suspect a lot of people
wouldn't have been so confused about what it does and how it needs to do
it, and wouldn't have tried to shoehorn it into the same corner of the
kernel as "suspend-to-ram" (where you really *can* do things like
"suspend" devices, and while they might certainly lose power in between,
they also really might not, and they certainly won't be *doing* things in
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/