Re: [PATCH 2/2] Fix console handling during suspend/resume

David Brownell
2006-06-15T16:43:04Z

On Thursday 15 June 2006 1:39 am, Pavel Machek wrote:
>
> > Actually it would be interesting to hear counter-arguments to this
> > position:
> >
> > We already HAVE that two-phase thing going on, at
> > least for swsusp. In phase I a PM_EVENT_FREEZE
> > gets sent. Then in phase II a PM_EVENT_SUSPEND gets
> > tries to really suspend things.
> >
> > One counter-argument might be that "phase I.5 resumes those devices"
> > is a problem. Another might be that "FREEZE should not be sent to
> > the console(s), the swap device, or their parents". I suspect there
> > are a few more issues mixed up in there too.
>
> This is FAQ:

Which seems to suggest that you are Frequently giving a useless
Answer to the Question ... and in this case, not the question
which was asked. You're doing that "attack the straw man"
thing again.

> Q: I do not understand why you have such strong objections to idea of
> selective suspend.

Not a question, and it's not clear who "you" is. Presumably, "Pavel"?
Plus it doesn't relate to the position sketched above.

> A: Do selective suspend during runtime power managment, that's
> okay. But
> its useless for suspend-to-disk. (And I do not see how you could use
> it for suspend-to-ram, I hope you do not want that).

That's a bunch of non-answers of course.

And re the parenthetical comment ... to use ACPI terminology for
just a moment (without assuming ACPI!), it's trivially true that
there are different device suspend states, and that real system
sleep states like S1 and S3 (plus many non-ACPI variants thereof)
can accomodate multiple device suspend states.

So for example a device enabled as a wakeup event source might use
a less aggressive suspend state than one which doesn't need to offer
any functionality while the system is in that sleep state. In
some cases those "less aggressive suspend" states _are_ exactly
equivalent to an un-suspended device. (Not with PCI PM of course,
but with some other hardware frameworks.)

> Lets see, so you suggest to

Actually I asked for counter-arguments to a position, which was
intended as a request not to enter the usual flamewar that shows
up whenever someone observes that Linux-PM has a few issues that
affect swsusp. At this time, I had offered no suggestion.

Those flames are, as always, tedious and needless.

> * SUSPEND all but swap device and parents
> * Snapshot
> * Write image to disk
> * SUSPEND swap device and parents
> * Powerdown
>
> Oh no, that does not work,

Oddly enough, it wasn't even mentioned in the position I was
asking a response to. This is what's called a "straw man"
attack ... when rather than actually address an issue that's
been raised, someone sets up a _different_ issue, attacks
that, and than treats the original issue as resolved:

http://www.nizkor.org/features/fallacies/straw-man.html

Attacking a straw man is as efficaceous as putting pins
into a voodoo doll ... at least, in terms of addressing
the original question.