[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <005101c6b4d2$f7506210$493d010a@nuitysystems.com>
Date: Mon, 31 Jul 2006 11:55:58 -0700
From: "Hua Zhong" <hzhong@...il.com>
To: "'Pavel Machek'" <pavel@....cz>
Cc: "'Rafael J. Wysocki'" <rjw@...k.pl>,
"'Bill Davidsen'" <davidsen@....com>,
"'Kernel Mailing List'" <linux-kernel@...r.kernel.org>
Subject: RE: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]
> > Suspend2 patch is open source. You can always take a look.
>
> swsusp is open source. You can always take a look. And you
> can always submit a patch.
>
> > Moreover, if someone claims suspend2 isn't ready for merge, or the
>
> Moreover, if someone claims swsusp is broken, they should
> attach bugzilla id.
Pavel,
You can't blame me for not doing these things, because I am not a maintainer.
However, you are, and you defend yourself so hard for that position, so if _you_
don't do these things, people complain.
> As you said, you do not know what you are talking about.
>
> He claims s-t-ram is easier than s-t-disk. That means that he did not do his
> homework, and did not check the archives on the subject.
Oh yeah? Let's check the archives:
"I seriously claim that STR _should_ be a lot simpler than suspend-to-disk,
because it avoids all the memory management problems. The reason that
we support suspend-to-disk but not STR is totally perverse - it's simply that
it has been easier to debug, because unlike STR, we can do a "real boot"
into a working system, and thus we don't have the debugging problems that
the "easy" suspend/resume case has."
http://thread.gmane.org/gmane.linux.power-management.general/1884/focus=2105
Maybe it's why he didn't like the STR design you had?
Maybe I am still wrong, maybe Linus is wrong too, but you can't attack me
not doing my homework.
Hua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists