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

[Pavel Machek <pavel@suse.cz>]

Hi!

> > It is slightly slower,
> 
> Sorry, but that is just unacceptable.

Eh? Slower suspend is not acceptable while slowing runtime system is
acceptable?

> > > The only con I see is the complexity of the code, but then again,
> > > Nigel
> > 
> > ..but thats a big con.
> 
> So why is that? From what I see, most of the code is completly independ
> of the rest of the kernel, and just does not affect if it is disabled.
> 
> It won't do any harm to the kernel, and again, Nigel is constantly
> improving that situation, so for sure, that is no _big_ con.

14000 lines is a lot of code to maintain.

> > > 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...
> 
> These "big changes" is something I have a problem with, since it means
> to delay a working suspend/resume in Linux for another "short-term" (so
> what does it mean: 1 month? six? twelve?). It is painful to get these
> things to work reliable, I have followed this for nearly 1.5 years. And
> again: today there is a working implementation, so why not merge it and
> have something today, and then start working on the other things.

swsusp is reliable; suspend2 is faster... If you can't wait six months
for uswsusp (which is as fast, today)... help me with uswsusp.

								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/