Hi! > > > > And we have different ideas about how things should be done. Userspace > > > > vs kernel space. Providing tuning knobs vs not. And so on. > > > > > > This isn't _that_ important. Actually, I'm not against an entirely in-kernel > > > solution, as there are some clear benefits of doing it this way. We only > > > need to be careful enough not to break the existing setups. > > > > Would you elaborate? > > One benefit is that we need not anything in the initrd for hibernation to work. > Another one is that we can get superior performance, for obvious reasons > (less copying of data, faster I/O). Yet another is simpler configuration and > no need to maintain a separate set of user space tools. I probably could > find more. > > > I would really hate to put progressbar painting into kernel; and if > > that's in userspace, we can do compression/encryption there too as > > well.... > > That's correct, we can. But since we have LZO in the kernel now, we can use > it for compression just as well, can't we? Yes, but we do not have progressbar painting in the kernel -- yet -- so users will still need initrd etc. Yes, we can move LZO into kernel pretty cheaply, and it will have minor benefit of slightly faster reguler swsusp, but... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
