* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I absolutely detest all suspend-to-disk crap. Quite frankly, I hate
> the whole thing. I think they've _all_ caused problems for the "true"
> suspend (suspend-to-ram), and the last thing I want to see is three or
> four different suspend-to-disk implementations. So unlike Ingo, I
> don't think "let's just integrate them all side-by-side and maintain
> them and look who wins" is really a good idea.
>
> How many different magic ioctl's does the thing introduce? Is it
> really just *two* entry-points (and how simple are they,
> interface-wise), and nothing else?
userspace-driven-suspend is already in the kernel, today. So it's not
really "two versions side by side doing the same thing", but more of:
A B C + D E F G H
where "ABC" is used by the uswsusp code today, and "ABCDEFGH" is used by
suspend2. So any "suspend2 merge" would largely be about adding "DEFGH".
(uswsusp of course redoes 'DEFGH' in user-space its own way, and there
is the inevitable "+" glue code as well, but it's at least not two
parallel versions of the same thing in the kernel, which would be
gross.)
My original mail was about the following thing: i tried the suspend2
patch (which just makes "echo disk > /sys/power/state" work as expected,
as long as you give the booting up kernel image an idea about where the
swap partition we suspended to is, via a single boot option) and that it
was pretty straightforward and worked well, and that i think its way of
reusing the existing suspend infrastructure and doing the add-ons
cleanly while keeping the existing user-hibernate code intact looked
viable to me.
I.e. to me it looked like while there are apparent conflicts of
personalities suspend2 did not really seem to be a hostile
reimplementation of 'A B C', but that it tries to build upon 'A B C' and
just has a different technical opinion about whether 'DEFGH' should be
in the kernel or outside of it.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
