Re: [Suspend2-devel] Re: uswsusp history lesson
From: Arjan van de Ven
Date: Mon Jul 10 2006 - 09:03:54 EST
On Mon, 2006-07-10 at 08:45 -0400, Thomas Tuttle wrote:
> First, let me say, I've gotten both swsusp and suspend2 to work, but
> I've had better luck with hardware under suspend2, and reading and
> writing the image was faster under suspend2.
>
> On July 10 at 05:18 EDT, Arjan van de Ven hastily scribbled:
> > As I said... if that is the case then it'd be easy to first merge "the
> > right basics", get that solid, and THEN add the features. So far I've
> > not seen that happen.
>
> So, you mean like merge just the freezer mods (if needed), and the
> suspend2 core, and then add the encryption/compression/filewriter/userui
> stuff separately?
yes. If suspend2 core is really better, that should be an improvement
already, without the additional complexity of the
encryption/compression/etc stuff. Get that merged, get it out there,
once a lot more people use it there may also be a lot more bug reports,
which are easier to fix in a low complexity environment. When that is
done, the encryption/compression/etc can be merged incrementally and
reviewed incrementally, on top of a stable basis.
When something is as tricky as suspend, the primary goal should be to
avoid complexity until things are stable. The suspend2 side of the house
seems to suggest the kernel.org state currently is not (I'm not going to
stick my hand in the hornest nest and agree or disagree), and if that's
indeed the case then just fixing that bit should be paramount, without
adding "unneeded" complexity at the same time.
This doesn't mean that I don't like any of those features. Don't get me
wrong there. It just means that I'm saying that adding those as a second
phase instead makes a whole lot of sense to me, just to keep the problem
clean.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/