> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/