Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > swsusp is also available today, and works better than you think. It is
> > slightly slower, but has all the other
> > features you listed in 2.6.16-rc3.
> 
> It is a lot slower because it does all it's I/O synchronously, doesn't 
> compress the image and throws away memory until at least half is
> free.

uswsusp does compress image (20% speedup, in recent CVS) and do
asynchronous I/O.

> > > The only con I see is the complexity of the code, but then again, Nigel
> >
> > ..but thats a big con.
> 
> It's fud. Hopefully as I post more suspend2 patches to LKML, people will see 
> that Suspend2 is simpler than what you are planning.

For what I'm planning, all the neccessary patches are already in -mm
tree. And they are *really* simple. If you can get suspend2 to 1000
lines of code (like Rafael did with uswsusp), we can have something to
talk about.

> > > From a user, and contributor, point of view, I really do not understand
> > > why not even trying to push a working implementation into mainline (I
> > > know that you cannot just apply the Suspend 2 patches and shipping it,
> >
> > It is less work to port suspend2's features into userspace than to make
> > suspend2 acceptable to mainline. Both will mean big changes, and may
> > cause some short-term problems, but it will be less pain than
> > maintaining suspend2 forever. Please help with the former...
> 
> That's not true. I've taken time to look at what would be involved in making 
> suspend2 match the changes you're doing, and I've decided it's just not worth 
> the effort.
> 
> Let's be clear. uswsusp is not really moving suspend-to-disk to userspace. 
> What it is doing is leaving everything but some code for writing the image in 
> kernel space, and implementing ioctls to give a userspace program the ability 
> to request that other processes be frozen, the snapshot prepared and so on. 
> Pages in the snapshot are copied to userspace, possibly compressed or 
> encrypted there in future, then fed back to kernel space so it can use the 
> swap routines to do the writing. Very little of substance is being done in 
> userspace. In short, all it's doing is adding the complexity of

Maybe very little of substance is being done in userspace, but all the
uglyness can stay there. I no longer need LZF in kernel, special
netlink API for progress bar (progress bar naturally lives in
userland), no plugin infrastructure needed, etc.

If you can do suspend2 without putting stuff listed above into kernel,
and in acceptable ammount of code... we can see. But you should really
put suspend2 code into userspace, and be done with that. Feel free to
spam l-k a bit more, but using existing infrastructure in -mm is right
way to go, and it is easier, too.
									Pavel
-- 
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/