Hi. On Thursday 12 July 2007 03:55:40 [email protected] wrote: > On Wed, 11 Jul 2007, Nigel Cunningham wrote: > > > Hi. > > > > On Wednesday 11 July 2007 21:11:34 Miklos Szeredi wrote: > >>> Anyway, to implement the kexec approach we must separate the > >>> hibernation from the suspend at the drivers level, which I'm still > >>> going to do, but I need to take part in endless discussions > >> > >> Discussions are good. We understand the problem better. Now I still > >> think we don't understand every aspect completely, so continuing the > >> discussion makes sense. > >> > >>> regarding the freezer, how it is bad and how we should drop it, > >>> because it breaks things (which NB is not true, because it doesn't). > >> > >> This thread started out from a bug, that seemed to be caused by the > >> freezer (we still don't exactly know what it was caused by), and the > >> discussion uncovered various problems _with_ the freezer, that up to > >> now no other _proper_ solutions have been propsed than to remove the > >> freezer. > > > > 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). > > I think the big problem with the existing freezer is that you want to stop > everything, except X, except Y, except Z..... > > the advantage of the new approaches being proposed is that they don't > require _anything_ from the origional system continue to run so you avoid > all the exceptions. > > freezing everything is easy, figuring out what you don't want to freeze is > where everyone is seeing problems. > > > 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? > > I think most people just see this as a symptom of the problem, not the > core problem itself. Sure, but before we go out and buy a new car, let's figure out properly what the problems with the old one are. It might just be that the horrendous sound that's making us want a new car isn't as bad as we initially think. Even if we do decide we want a new version, we can at least learn something from the old one. Regards, Nigel -- See http://www.tuxonice.net for Howtos, FAQs, mailing lists, wiki and bugzilla info.
Attachment:
pgpdMUE5GM8kG.pgp
Description: PGP signature
- References:
- Prev by Date: Re: x86 status was Re: -mm merge plans for 2.6.23
- Next by Date: Re: acpi regression on some laptops
- Previous by thread: Re: Hibernation Redesign
- Next by thread: Re: Hibernation Redesign
- Index(es):
 |