Hi.

On Wednesday 11 July 2007 23:16:41 Jeremy Maitin-Shepard wrote:
quoted text
> Nigel Cunningham <nigel@nigel.suspend2.net> writes:
>=20
> [snip]
>=20
> > No other _proper_ solutions have been proposed. Everyone who suggests=20
removing=20
quoted text
> > the freezer also suggests implementing it all over again. It might be=20
sending=20
quoted text
> > SIGSTOP to everything. It might be shifting the desk chairs around and=
=20
quoted text
> > creating a completely new kernel context, but they always have the same=
=20
quoted text
> > goal - stopping the existing activity, and they all come with their own=
=20
quoted text
> > issues (even if they're not obvious yet because the alternatives are=20
> > currently vapourware to one extent or another).
>=20
> I'll certainly admit the kexec idea is vaporware currently, but it does
> differ in a significant way from freezer-based approaches, such that I
> don't think it should be referred to as just another implementation of a
> freezer.  Specifically, it doesn't require that the "old kernel" be in a
> "consistent" state to a greater extent than suspend to ram; it is the
> case that all of the devices must be quiesced or shut down to some
> extent, but doing this without races and deadlocks (and without the
> freezer) is certainly very, very similar to what needs to be done for
> suspend to ram, which will need to be solved anyway.  Unlike the
> existing hibernate approaches, however, it will not be necessary to use
> any of the driver infrastructure once switched to the "save image"
> kernel, and thus it will not matter what locks are held, for instance.

Locks are not nearly the issue that you're making them out to be, and neith=
er=20
are most processes. It's only fuse that has caused this whole ding.

The lack of context from the original kernel is also going to be a problem.=
 If=20
you want to store the image on a local hard disk, the kernel being hibernat=
ed=20
is going to need to do that for you, because it will need to use the=20
information only it has regarding what swap is in use, how files on mounted=
=20
filesystems map to devices and sectors and so on. It will need to somehow=20
transfer that information from itself to the 'saving kernel'. In the end, t=
he=20
only advantage you'll get is that you don't have to worry about fuse=20
processes anymore.

=46rankly, I wish kexec was a viable alternative. I'm tired of working on k=
ernel=20
code, and would be perfectly happy to stop working on Suspend2 if kexec wou=
ld=20
work or if Rafael got swsusp to a point where the difference in features wa=
s=20
minimal. But I just can't see that kexec is a viable alternative. Sorry.

Nigel
=2D-=20
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.