Absolutely.
Two big reasons:
- debuggability
I know we don't do this correctly right now, but I want to be able to
at least feel like we can some day actually do printk's etc through 99%
of the suspend/resume cycle. It's a *huge* thing for debugging problems
that happen in the wild, and one of the biggest issues is that we
currently usualyl just get a "the machine died" message when suspend or
resume doesn't work.
Yes, doing printk's to the Intel management flash stuff can help a lot
here, and I want that too, but I'd really like to shut down consoles
individually rather than having the "big hammer" approach that shuts
them up entirely over the whole suspend/resume sequence (or not at all,
if you use "no_console_suspend").
And I'd *really* like to do things like VGA-console shutdown in the
late phase (and resume early).
- it's actually likely *much* simpler for some devices.
Simple devices (and that includes things like PCI bridges etc, but
also potentially USB host controllers etc) are things that can often be
trivially suspended - all the complexity is really not in the
controller itself, but beyond, in the bus that it actually drives.
And the late-suspend/early-resume means that you don't have to worry
about things like interrupts happening while you're suspended. Yes,
putting the device into D3 will disable interrupts from that device too
(unless there are bugs), *BUT* you may be sharing an interrupt line,
and interrupts may be posted and delayed, so an earlier interrupt may
well be pending etc.
suspending late and resuming early just avoids those issues entirely.
Sometimes these things interact. For example, firewire is certainly not
trivial to suspend as a "subsystem" thing (ie all the devices behind the
firewire bridge need to do magic things, like spinning down etc that
obviously can not happen in the final "late" phase), but the firewire
controller itself is likely trivial to suspend/resume and can easily be
handled in the late/early routines. And guess what? It's also exactly what
you want to happen in case you end up using the firewire RDMA as a debug
aid.
IOW, you want that firewire controller (and the PCI bridges) working
really early, so that if a problem does happen when you resume some more
complex device (say, one of the graphics chips that need X to really come
alive), you can use the firewire rdma to read out the kernel log buffer
from memory.
I don't personally mind kexec at all, but on the other hand, I don't care
about suspend-to-disk in the first place. I do know that some people
really don't want it, and I suspect that they have valid reasons. Ranging
from memory use to simply just performance.
Linus
--
