Hi.

On Tuesday 03 July 2007 15:48:26 Benjamin Herrenschmidt wrote:
quoted text
>=20
> > Note, though, that this won't help at all when people use=20
the "suspend-to-ram=20
quoted text
> > instead of powering down after writing a hibernation image" feature in=
=20
quoted text
> > (uswsusp | tuxonice). Fuse is just a broken idea in the first place, bu=
t=20
quoted text
> > given that it exists, we still need to find the underlying cause.
>=20
> No, Fuse is not a broken idea in the first place. It's the freezer that
> is a totally broken idea. It has proven many times to be racy by design
> and cannot be made right. Ther usermode helper mess is just part of
> that, fuse is another example, etc etc ...

To some extent, I agree. I think the ideal solution would be to simply not=
=20
schedule processes that are supposed to be frozen. But who wants to play wi=
th=20
scheduler code? Not me!

quoted text
> So I think Matthew is totally right. In fact, the presence of the
> freezer is the main reason why Paulus so far NACKed Johannes attempts at
> merging the PPC PM code with the generic code in kernel/power.c
>=20
> We've been doing fine without it so far and intend to continue to do so.

=46use depends on !PPC?
=20
quoted text
> As for suspend-to-disk, I refer you to the discussions we had in the
> past with Linus, where he explains I think quite clearly how wrong the
> current implementation of STR is :-)

I assume you mean STD. The problem there is that Linus doesn't care about S=
TD.=20
If he did, I dare say he'd think through the issues more thoroughly than he=
=20
apparently has.
=20
quoted text
> Thing is, if you're going to do snapshots, you should probably not sync
> after you have "frozen" anyway.

=46ully agree. But how do you stop things syncing while you're writing the =
image=20
if you don't have a freezer or equivalent? (scheduler based, kexec.. they'r=
e=20
all workarounds for this issue).

Regards,

Nigel
=2D-=20
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia