[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1I8bEi-0000HF-00@dorka.pomaz.szeredi.hu>
Date: Wed, 11 Jul 2007 14:24:04 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: nigel@...el.suspend2.net
CC: miklos@...redi.hu, rjw@...k.pl, a1426z@...ab.com, jeremy@...p.org,
jbms@....edu, pavel@....cz, nickpiggin@...oo.com.au,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: Hibernation Redesign
> No other _proper_ solutions have been proposed. Everyone who suggests removing
> the freezer also suggests implementing it all over again. It might be sending
> SIGSTOP to everything. It might be shifting the desk chairs around and
> creating a completely new kernel context, but they always have the same
> goal - stopping the existing activity, and they all come with their own
> issues (even if they're not obvious yet because the alternatives are
> currently vapourware to one extent or another).
Hey, I know precious little about drivers and power management, but I
can clarly see, that
a) stopping all tasks and requiring them to finish any syscall they
are in
b) stopping tasks _in the driver_ that are trying to access the
harware during/after suspend
are completely different solutions, the later being much more fine
grained and not having all of the mentioned problems that the former
exhibits.
> IMHO, the real solution is to go back to the original issue and fix it
> properly. Make fuse filesystems play nicely with the existing freezer. I've
> just gone back and looked at the point where you started talking
> about "malicious filesystems". You talk about fuse imposing certain ordering
> in the userspace tasks being frozen. Please, say more. What ordering issues?
> Why? How can such ordering be determined programmatically?
It can't. If you are interested, please read through that thread. If
something's still not clear, let's discuss it further.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists