RE: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

RE: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Hua Zhong]

> http://thread.gmane.org/gmane.linux.power-management.general/1884/focus=2105

Correct link before anyone asks:

http://article.gmane.org/gmane.linux.power-management.general/1974

Hua

the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

[Hans Reiser]

Is http://wiki.kernelnewbies.org/WhyReiser4IsNotIn truly the "official"
point of view as claimed by its author?  An interesting method of
expression for it.  I heard about it from a user who suggested that I
respond before it got slashdotted.

Let me ask that one compare and contrast the ext4 integration procedure
outlined by Ted Tso, with the procedure experienced by other
filesystems.  The code isn't even written, benchmarked, or tested yet,
and it is going into the kernel already so that its developers don't
have to deal with maintaining patches separate from the tree.  Wow. 
Kind of hard to argue that it is not politically differentiated, isn't it?

Consider what happened with XFS as the article writer mentions.  I met
the original XFS team, led by two very senior developers (Jim Grey, and
another fellow whose name I am blanking on, forgive me, I learned much
from him in just a few conversations).  They were kind enough to
instruct me on what ideas I should take from XFS, and you know what, I
listened.  Reiser4's allocate on flush is the result of their kind
instruction.  I then took it a bit further, like a good student, and
Reiser4 also has balance on flush, compress on flush, etc.

These guys wanted to port XFS to Linux, but there was a problem, which
was that IRIX was better in some ways than Linux, and XFS depended on
those advantages.  Now I met them, and I have to tell you that it was
pretty obvious that these guys knew what they were doing.  Suggest that
these guys needed supervision --- sorry, no way, we needed their
supervision.  What happened?  They got hassled.  Instead of learning
from them, welcoming into our community two very senior developers who
knew a lot more than any of us about the topics they chose to speak
about, they got hassled, they get ignored, they felt rejected, and left
the Linux community forever, never to return.  XFS is still with us, but
the loss of those two could only have been devastating for their
project.    I think the whole kernel community suffered from their loss.

Linux has a problem, which is that with success it is attracting people
with more skill than what it started with, and it is not doing a very
good job of handling that.  In fact, it downright stinks at it, behaving
in the worst way it could choose for handling that.  We have lost quite
a number of FS developers who just don't want to deal with people who
know less than they do but are obnoxious and disrespectful to
submissions because they enjoy powertripping.  We lost David Mazieres,
for example, because he is very very bright, is one of DARPA's most
promising security researchers, and he does not want to be bothered with
Viro et al. so he develops for BSD instead.  Linus, if you really want
to prove that Linux welcomes talented people, go sweet talk Mazieres
into giving Linux another try, you might succeed if you try.  The odd
thing is that Viro is not obnoxious at all in person.  lkml suffers from
email disease, and we need to make conscious efforts to reduce that.

Regarding distros accepting filesystems first, that is just completely
backwards from what it ought to be.  Linus, I respect you a lot, but I
know this one is your idea, and some things I disagree with you on. 
Distros are marketed towards people who do not know how to tar and untar
if an FS is dropped.  A reasonable approach would be to say that any
filesystem marked as experimental can be dropped at any time, so if you
aren't able to tar and untar the partition it is on when a new kernel
comes out, you should not use experimental filesystems.  Then most
distros will not make the experimental FS visible to users who don't
press three buttons acknowledging that they were warned....  Linspire's
view is pretty simple, they need to know that Reiser4 will be accepted
BEFORE they make their distro depend on it.  This is being responsible
to their users.  I could go ask Debian, etc., to include Reiser4, but it
is the wrong way, so I am shy about it.

I am not saying that ext4 should not be accepted as an experimental FS,
I don't even really believe that ext4 should only be accepted when it is
higher performance than Reiser4, I am saying that the process should be
the same for everyone.  Reiser4 is the upgrade for ReiserFS V3, in which
we fix all of V3's flaws without disturbing the mission critical servers
using V3 by changing the V3 code underneath them.  (Things like the bug
affecting MythTV users on V3 at the moment just should not be
happening.  Experiments belong in V4, and I wish there was more respect
for my views on this.).  V4 contains bug fixes for several V3 bugs that
are too deep to fix without deep rewrite, and since V3 does not have
plugins, disk format changes should not get added to a stable branch. 
When submitted Reiser4 was more stable than V3 was when it was
accepted.  (This is because we now have a much better test suite.   I
would never submit code that I know has a bug unfixed.  At the moment we
can crash Reiser4 using our test suite, as some of the linux kernel
inclusion related changes made recently were extensive, I hope we have
that bug fixed by next week.)

We should develop a culture in which acceptance is more based on whose
code measurably performs well than on who is friends with whom.  We
should not think that such a culture will develop without an effort
being made to grow it.

Actually, if we just had a few more akpms to go around, things would be
a lot better..... oh well.  We need to recruit more people like him. 
You can't really have code reviewed by persons less experienced and
proven than those being reviewed, it just doesn't work too well.  Linux
needs to look outward more, and welcome persons who have proven
themselves in other arenas as though we were lucky to get their time. 
Because we are.  Maybe when we don't have people with the expertise to
review something, we should go outside the Linux community, like the way
academic journals will solicit outside reviewers for particular articles
as they need them.  Our current attitude resembles that of BSD before it
lost the market to Linux, I remember it well, there was a reason why I
developed for Linux instead.

Avoiding the problems that some large corporations have with politics
does not happen automatically as a result of it being free software, it
requires as much effort as it does in the successful large
corporations.  Non-profits are in no way immune to being harmed by
internal politics.

If it is true that Reiser4 is likely to go in for 2.6.19, this is good
to hear, though an odd source to hear it from.  If it is true, then I
will skip lobbying distros to accept Reiser4 before the kernel does,
because really it makes little sense for them to do so.

Hans

Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

[Theodore Tso]

On Fri, Jul 21, 2006 at 01:46:18PM -0600, Hans Reiser wrote:
> Let me ask that one compare and contrast the ext4 integration procedure
> outlined by Ted Tso

"integration procedure" is hardly an accurate description, rather it
is a development procedure that was developed after discussion and
consensus building across LKML and the ext2/3/4 development team.  It
was not the original plan put forth by the ext2 developers, but after
listening to the concerns and suggestions, we did not question the
motives of the people making suggestions; we listened.

> The code isn't even written, benchmarked, or tested yet,

Actually, the first bits that we plan to merge have already been
written and in use by hundreds of clusterfs customers, posted to LKML
for comments (and we don't attack our reviewers, we thank them for
their comments), and in fact they were written about at last year's
OLS complete with benchmarks and graphs.
(http://ext2.sourceforge.net/2005-ols/2005-ols-ext3.html)

> Consider what happened with XFS as the article writer mentions.  I met
> the original XFS team, led by two very senior developers (Jim Grey, and
> another fellow whose name I am blanking on, forgive me, I learned much
> from him in just a few conversations).  

I believe you are referring to Jim Mostek and Steve Lord, and yes,
they were very talented developers and engineers.  I very much enjoyed
talking to them at various filesystem and Linux conferences and
workshops.

> supervision.  What happened?  They got hassled.  Instead of learning
> from them, welcoming into our community two very senior developers who
> knew a lot more than any of us about the topics they chose to speak
> about, they got hassled, they get ignored, they felt rejected, and left
> the Linux community forever, never to return.  

That's hardly what happened.  SGI went through layoffs, and they were
hit.  See:  http://slashdot.org/articles/01/05/26/0743254.shtml

> A reasonable approach would be to say that any
> filesystem marked as experimental can be dropped at any time, so if you
> aren't able to tar and untar the partition it is on when a new kernel
> comes out, you should not use experimental filesystems.  Then most
> distros will not make the experimental FS visible to users who don't
> press three buttons acknowledging that they were warned....  Linspire's
> view is pretty simple, they need to know that Reiser4 will be accepted
> BEFORE they make their distro depend on it.  

You do realize these two statements are completely contradictory,
don't you?  If an experimental filesystem can be dropped at any time,
then Linspire can't depend on it from the point of view of supporting
their users.  If there is a huge user base, then someone is going to
have to maintain it, even if the developer community has moved on to
supporting the next new exciting filesystem thing.  Hence, it is
critical that the resulting filesystem be fully maintainable before it
is integrated.  To put it in your words, it wouldn't be responsible to
the user base to do otherwise.

							- Ted

Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

[Steve Lord]

Theodore Tso wrote:
> On Fri, Jul 21, 2006 at 01:46:18PM -0600, Hans Reiser wrote:

>> Consider what happened with XFS as the article writer mentions.  I met
>> the original XFS team, led by two very senior developers (Jim Grey, and
>> another fellow whose name I am blanking on, forgive me, I learned much
>> from him in just a few conversations).  

Not sure who Jim Grey was, he never worked on XFS, ah well.

> 
> I believe you are referring to Jim Mostek and Steve Lord, and yes,
> they were very talented developers and engineers.  I very much enjoyed
> talking to them at various filesystem and Linux conferences and
> workshops.
> 
>> supervision.  What happened?  They got hassled.  Instead of learning
>> from them, welcoming into our community two very senior developers who
>> knew a lot more than any of us about the topics they chose to speak
>> about, they got hassled, they get ignored, they felt rejected, and left
>> the Linux community forever, never to return.  
> 
> That's hardly what happened.  SGI went through layoffs, and they were
> hit.  See:  http://slashdot.org/articles/01/05/26/0743254.shtml
> 

Ted, you of all people should know not believe all you read on
slashdot ;-) 'Linuxcare helping out with the funding' ha!

Both Jim Mostek and I left under our own steam at different times, Jim
in 2000 and myself in 2003. SGI still has great technology to work on
and, but the you can only take so many years of bad financial results
and watching people get layed off.

I still work on Linux, and follow development as much as I can. I keep
trying  to get back to OLS, but circumstances keep conspiring against
me, maybe next year.

Steve Lord

Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

[Nikita Danilov]

Steve Lord writes:
 > Theodore Tso wrote:
 > > On Fri, Jul 21, 2006 at 01:46:18PM -0600, Hans Reiser wrote:
 > 
 > >> Consider what happened with XFS as the article writer mentions.  I met
 > >> the original XFS team, led by two very senior developers (Jim Grey, and
 > >> another fellow whose name I am blanking on, forgive me, I learned much
 > >> from him in just a few conversations).  
 > 
 > Not sure who Jim Grey was, he never worked on XFS, ah well.

I believe the (mis-)reference is to a famous data-base person, co-author
of "Transaction Processing". He is with Microsoft now
(http://research.microsoft.com/~Gray/JimGrayHomePageSummary.htm).

 > 
 > Steve Lord

Nikita.

Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

[Theodore Tso]

On Mon, Jul 24, 2006 at 11:53:08AM +0400, Nikita Danilov wrote:
> 
> I believe the (mis-)reference is to a famous data-base person, co-author
> of "Transaction Processing". He is with Microsoft now
> (http://research.microsoft.com/~Gray/JimGrayHomePageSummary.htm).
> 

That's what I thought when I saw the name Jim Gray, but as far as I
knew he never worked on XFS and never left the Linux community
dejected because Linux kernel coding standards requirements before
changes were allowed to be merged, when Hans did his name dropping
thing.

(I mean geez, if you want really high standards before new code is
accepted, take a look at Open Solaris; they have *such* a heavyweight
process, with two mandatory signoffs by core Solaris engineers who
both have to do a line-by-line review, and with a promise of on-disk
and ABI compatibility *forever* ---- that we do more commits in a week
than they do in a year....)

						- Ted

Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

[Olivier Galibert]

On Mon, Jul 24, 2006 at 06:30:23AM -0400, Theodore Tso wrote:
> (I mean geez, if you want really high standards before new code is
> accepted, take a look at Open Solaris; they have *such* a heavyweight
> process, with two mandatory signoffs by core Solaris engineers who
> both have to do a line-by-line review, and with a promise of on-disk
> and ABI compatibility *forever* ---- that we do more commits in a week
> than they do in a year....)

That sounds almost like gcc, only worse.

I think there is something of a problem currently, tough.  It is
getting too hard to get code in if you're not a maintainer for an
existing subsystem (reiser4, suspend2...), and too easy when you're a
maintainer (ext4, uswsusp...).  Ext patches don't get reviewed much
outside of the developpers, and they go in pretty much without
discussion in any case, except when Linus blows a fuse.  Reiser4 would
have be in without discussion if it had been a set of patches through
time to reiser3, and would have been called 4 only when Linus yelled.
I suspect some balancing would be useful.

  OG.

Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

[Theodore Tso]

On Mon, Jul 24, 2006 at 01:35:34PM +0200, Olivier Galibert wrote:
>Ext patches don't get reviewed much
> outside of the developpers, and they go in pretty much without
> discussion in any case, except when Linus blows a fuse.

Um, you're kidding, right?  We certainly don't make the assumption
that we can violate CodingStyle willy nilly and stuff in yacc grammers
into ext3 and assume that no one will push back.

In fact we did a lot of work to make sure the patches were clean and
mostly ready to be accepted to mainline even before we made the first
proposal to push extents to LKML.

> I think there is something of a problem currently, tough.  It is
> getting too hard to get code in if you're not a maintainer for an
> existing subsystem (reiser4, suspend2...), and too easy when you're a
> maintainer (ext4, uswsusp...).  

It's not fair to assume that the only reason why non-maintainers have
a harder time getting changes is because their changes are getting
more intensive review.  (Although it is the case that we probably do
need to get better at reviewing changes that go in via git trees.)  A
much more important effect is that non-maintainers aren't familiar
with coding and patch submission guidelines.  For example, in
suspend2, Nigel first tried with patches that were too monolithic, and
then his next series was too broken down such that it was too hard to
review (and "git bisect" wouldn't work).  And of course, there are
people who assume that the rules shouldn't apply to their filesystem...

						- Ted

Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

[Olivier Galibert]

On Mon, Jul 24, 2006 at 09:39:39AM -0400, Theodore Tso wrote:
> On Mon, Jul 24, 2006 at 01:35:34PM +0200, Olivier Galibert wrote:
> >Ext patches don't get reviewed much
> > outside of the developpers, and they go in pretty much without
> > discussion in any case, except when Linus blows a fuse.
> 
> Um, you're kidding, right?  We certainly don't make the assumption
> that we can violate CodingStyle willy nilly and stuff in yacc grammers
> into ext3 and assume that no one will push back.

I'm not kidding.  I do recognise that the ext* maintainers do a very
good and clean job.


> In fact we did a lot of work to make sure the patches were clean and
> mostly ready to be accepted to mainline even before we made the first
> proposal to push extents to LKML.

I'm no talking about extends only.  Ext3 now is very, very different
than the ext2+journal it was at the start, with backwards-incompatible
format changes added all the time[1].  These changes went in
no-questions-asked.


> > I think there is something of a problem currently, tough.  It is
> > getting too hard to get code in if you're not a maintainer for an
> > existing subsystem (reiser4, suspend2...), and too easy when you're a
> > maintainer (ext4, uswsusp...).  
> 
> It's not fair to assume that the only reason why non-maintainers have
> a harder time getting changes is because their changes are getting
> more intensive review.

"only", no, definitively not.  The impact is non-negligible though.


> (Although it is the case that we probably do
> need to get better at reviewing changes that go in via git trees.)

Ohh yes, a lot better.  Just look at ALSA, most of SNDRV_HWDEP* should
never have gotten in in the first place, especially some recent ones
like SNDRV_HWDEP_IFACE_SB_RC, and even some (SNDRV_HWDEP_IFACE_USX2Y*)
are security holes the size of Cleveland.  I need to continue
documenting the Alsa kernel interface, but I need a new bucket, the
first one is overflowing.


> A much more important effect is that non-maintainers aren't familiar
> with coding and patch submission guidelines.  For example, in
> suspend2, Nigel first tried with patches that were too monolithic,
> and then his next series was too broken down such that it was too
> hard to review (and "git bisect" wouldn't work).

All his submissions since 2004 or so?  It's a little easy to limit
oneself to the last two ones.


> And of course, there are people who assume that the rules shouldn't
> apply to their filesystem...

It may be a little hard to remove XFS at that point though...  And,
while it's not a filesystem, I'd love to be pointed to the technical
discussion deciding whether uswsusp is a good idea.

  OG.

[1] All optional, I know.

Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

[Pavel Machek]

Hi!

> > A much more important effect is that non-maintainers aren't familiar
> > with coding and patch submission guidelines.  For example, in
> > suspend2, Nigel first tried with patches that were too monolithic,
> > and then his next series was too broken down such that it was too
> > hard to review (and "git bisect" wouldn't work).
> 
> All his submissions since 2004 or so?  It's a little easy to limit
> oneself to the last two ones.

Nigel did not do any submissions in 2004 or so. Check your fact, that
stuff was marked 'RFC' and yes I did comment on it.

He did 1 (one) submission that looked like SubmittingPatches at the
first sight, and that was very recent.

Stop spreading lies.

							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

[Olivier Galibert]

On Wed, Jul 26, 2006 at 01:08:06PM +0000, Pavel Machek wrote:
> Hi!
> 
> > > A much more important effect is that non-maintainers aren't familiar
> > > with coding and patch submission guidelines.  For example, in
> > > suspend2, Nigel first tried with patches that were too monolithic,
> > > and then his next series was too broken down such that it was too
> > > hard to review (and "git bisect" wouldn't work).
> > 
> > All his submissions since 2004 or so?  It's a little easy to limit
> > oneself to the last two ones.
> 
> Nigel did not do any submissions in 2004 or so. Check your fact, that
> stuff was marked 'RFC' and yes I did comment on it.

2004-09-16 submission:

http://lkml.org/lkml/2004/9/16/76
http://lkml.org/lkml/2004/9/16/77
http://lkml.org/lkml/2004/9/16/78
http://lkml.org/lkml/2004/9/16/81
http://lkml.org/lkml/2004/9/16/82
http://lkml.org/lkml/2004/9/16/83
http://lkml.org/lkml/2004/9/16/86
http://lkml.org/lkml/2004/9/16/87
http://lkml.org/lkml/2004/9/16/89
http://lkml.org/lkml/2004/9/16/90


2004-11-24 submission:

http://lkml.org/lkml/2004/11/24/93
http://lkml.org/lkml/2004/11/24/94
http://lkml.org/lkml/2004/11/24/95
http://lkml.org/lkml/2004/11/24/96
http://lkml.org/lkml/2004/11/24/97
http://lkml.org/lkml/2004/11/24/98
http://lkml.org/lkml/2004/11/24/100
http://lkml.org/lkml/2004/11/24/101
[58 mails or so total]


> He did 1 (one) submission that looked like SubmittingPatches at the
> first sight, and that was very recent.
> 
> Stop spreading lies.

I am awaiting your apologies.

  OG.

suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Pavel Machek]

Hi!

> > > > A much more important effect is that non-maintainers aren't familiar
> > > > with coding and patch submission guidelines.  For example, in
> > > > suspend2, Nigel first tried with patches that were too monolithic,
> > > > and then his next series was too broken down such that it was too
> > > > hard to review (and "git bisect" wouldn't work).
> > > 
> > > All his submissions since 2004 or so?  It's a little easy to limit
> > > oneself to the last two ones.
> > 
> > Nigel did not do any submissions in 2004 or so. Check your fact, that
> > stuff was marked 'RFC' and yes I did comment on it.
> 
> 2004-09-16 submission:
> 
> http://lkml.org/lkml/2004/9/16/76
...
> http://lkml.org/lkml/2004/9/16/90

Yes, Nigel submitted part of suspend2 here (I do not think he
submitted compression code on that day, for example), but then

http://lkml.org/lkml/2004/9/16/347

came:

#I should mention, I'm planning on producing a BK tree with these patches
#(and ones to fix issues raised), so you won't have to include a long
#list in -mm eventually! It will be on suspend2.bkbits.net (not there
#yet).

That sounds like "don't merge it yet, I'll prepare better version" to
me.

> 2004-11-24 submission:
> 
> http://lkml.org/lkml/2004/11/24/93
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Okay, this one is important. It starts with 

#Hi everyone.
#
#I know that I still have work to do on suspend2, but thought it was high
#time I got around to properly submitting the code for review, so here goes.

That looks like request for review, not request for merge. Plus it was
to: lkml, while it should be to: maintainer (or maybe to: akpm). Well,
it also says "Suspend 2 merge" in subject..
 
> > He did 1 (one) submission that looked like SubmittingPatches at the
> > first sight, and that was very recent.
> > 
> > Stop spreading lies.
> 
> I am awaiting your apologies.

Okay, 11/24 looked closer to submission than I recalled. So I guess I
have to say "sorry".

So we have 1 submission for review in 11/2004 and 1 submission for -mm
merge in 2006, right?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Olivier Galibert]

On Thu, Jul 27, 2006 at 11:42:25PM +0200, Pavel Machek wrote:
> So we have 1 submission for review in 11/2004 and 1 submission for -mm
> merge in 2006, right?

Wrong.  I gave a list of dates at the beginning of the month, do you
think I threw dice to get them?

And could you explain, as suspend maintainer for the linux kernel, how
come code submitted for the first time two years ago and with a much
better track record than the in-kernel one is still not in?

  OG.

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Pavel Machek]

On Fri 28-07-06 01:22:49, Olivier Galibert wrote:
> On Thu, Jul 27, 2006 at 11:42:25PM +0200, Pavel Machek wrote:
> > So we have 1 submission for review in 11/2004 and 1 submission for -mm
> > merge in 2006, right?
> 
> Wrong.  I gave a list of dates at the beginning of the month, do you
> think I threw dice to get them?
> 
> And could you explain, as suspend maintainer for the linux kernel, how
> come code submitted for the first time two years ago and with a much
> better track record than the in-kernel one is still not in?

Because Nigel has too much of code to start with, and refuses to fix
his design because it would invalidate all the stabilization work.

Plus Nigel did not do very good job with submitting those patches.
							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Bill Davidsen]

Pavel Machek wrote:
> On Fri 28-07-06 01:22:49, Olivier Galibert wrote:
>> On Thu, Jul 27, 2006 at 11:42:25PM +0200, Pavel Machek wrote:
>>> So we have 1 submission for review in 11/2004 and 1 submission for -mm
>>> merge in 2006, right?
>> Wrong.  I gave a list of dates at the beginning of the month, do you
>> think I threw dice to get them?
>>
>> And could you explain, as suspend maintainer for the linux kernel, how
>> come code submitted for the first time two years ago and with a much
>> better track record than the in-kernel one is still not in?
> 
> Because Nigel has too much of code to start with, and refuses to fix
> his design because it would invalidate all the stabilization work.

Why should he invalidate his stabilization work, and what's in need of 
fixing? The suspend in the kernel is great, but suspend2 includes both 
suspend and working resume code as well.
> 
> Plus Nigel did not do very good job with submitting those patches.

They apply, they work. What's not very good about that? Is this being 
blocked because of a spelling error, or did he mess up the indenting on 
"signed off by" or what? I realize you may have something other than the 
download version, but it's been years now.

I would like to see the working suspend (suspend2) in the kernel, and 
users wanting to debug the resume stuff currently in the kernel could 
get it under EXPERIMENTAL or some such.

-- 
Bill Davidsen <davidsen@tmr.com>
   Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Rafael J. Wysocki]

On Saturday 29 July 2006 21:23, Bill Davidsen wrote:
> Pavel Machek wrote:
> > On Fri 28-07-06 01:22:49, Olivier Galibert wrote:
> >> On Thu, Jul 27, 2006 at 11:42:25PM +0200, Pavel Machek wrote:
> >>> So we have 1 submission for review in 11/2004 and 1 submission for -mm
> >>> merge in 2006, right?
> >> Wrong.  I gave a list of dates at the beginning of the month, do you
> >> think I threw dice to get them?
> >>
> >> And could you explain, as suspend maintainer for the linux kernel, how
> >> come code submitted for the first time two years ago and with a much
> >> better track record than the in-kernel one is still not in?
> > 
> > Because Nigel has too much of code to start with, and refuses to fix
> > his design because it would invalidate all the stabilization work.
> 
> Why should he invalidate his stabilization work, and what's in need of 
> fixing? The suspend in the kernel is great, but suspend2 includes both 
> suspend and working resume code as well.
> > 
> > Plus Nigel did not do very good job with submitting those patches.
> 
> They apply, they work. What's not very good about that? Is this being 
> blocked because of a spelling error, or did he mess up the indenting on 
> "signed off by" or what? I realize you may have something other than the 
> download version, but it's been years now.
> 
> I would like to see the working suspend (suspend2) in the kernel, and 
> users wanting to debug the resume stuff currently in the kernel could 
> get it under EXPERIMENTAL or some such.

You probably don't realize how offensive this is.

Actually some people have been working really hard to make the in-kernel
code work and you could just respect that.

Now, please note the swsusp resume code works for me 100% of the time
and I know of many people who use it without any problems.  Also I know of
some people for whom suspend2 doesn't work.  Please take this into
consideration.

Moreover, if the swsusp's resume doesn't work for you and suspend2's resume
does, this probably means that suspend2 contains some driver fixes that
haven't been submitted for merging.

Greetings,
Rafael

RE: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Hua Zhong]

> Moreover, if the swsusp's resume doesn't work for you and 
> suspend2's resume does, this probably means that suspend2 
> contains some driver fixes that haven't been submitted for merging.

This statement worries me for several reasons.

First, I've seen repeatedly blame for "drivers". People might buy it if there was not a working suspend2. I never saw Nigal blame
drivers; instead he makes sure to provide working code. In the end, users want a working suspend, and that's what counts.

Second, if the current swsusp maintainers have genuine interest for the users (not just "it works on my machine"), I would think
they'd have taken a serious look at why suspend2 has a higher success rate. But from the above comment, you are not even sure why
that is, and could only speculate "this probably means (drivers)". I could hardly be convinced that the current maintainers have
been trying to work with Nigal to improve Linux suspend.

At last, "maintainer" is not just a title or a feeling of superiority, it's a responsibility of providing a great system to the
users. I'll just quote Linus when he was flaming suspend-to-ram a couple of months ago. Replace it with suspend-to-disk at your own
will:

"The fact that worries me is that suspend-to-ram DOES NOT WORK FOR PEOPLE. 
I have never _ever_ met a laptop or machine of mine that "just worked". 
I've always had to fix something, and people always end up having to do 
something ridiculous like unlink all modules etc.

If that isn't what worries you, you're on the wrong page."

http://article.gmane.org/gmane.linux.power-management.general/2105

Hua

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Rafael J. Wysocki]

On Saturday 29 July 2006 23:56, Hua Zhong wrote:
> > Moreover, if the swsusp's resume doesn't work for you and 
> > suspend2's resume does, this probably means that suspend2 
> > contains some driver fixes that haven't been submitted for merging.
> 
> This statement worries me for several reasons.
> 
> First, I've seen repeatedly blame for "drivers". People might buy it if
> there was not a working suspend2. I never saw Nigal blame 
> drivers;

I don't _blame_ drivers.  I only wanted to say this: "If Nigel knows that some
drivers need to be fixed and he has working fixes for these drivers, he
should have submitted these fixes for merging instead of just keeping
them in suspend2".  Period.

If I know of a fix for a driver, I always do my best to make sure the fix
will get considered for merging at least.  The problem is I'm not a driver
expert and I can't provide the fixes myself.

> instead he makes sure to provide working code. In the end, users want
> a working suspend, and that's what counts.  
> 
> Second, if the current swsusp maintainers have genuine interest for the
> users (not just "it works on my machine"), I would think they'd have taken
> a serious look at why suspend2 has a higher success rate. But from the
> above comment, you are not even sure why  that is, and could only speculate
> "this probably means (drivers)".

No, I'm not sure.  If I were, I would fix the problem.  Also I'm not quite sure
about the higher success rate of suspend2.

> I could hardly be convinced that the current maintainers have been trying to
> work with Nigal to improve Linux suspend.

This is an offensive comment.

> At last, "maintainer" is not just a title or a feeling of superiority, it's
> a responsibility of providing a great system to the users. I'll just quote
> Linus when he was flaming suspend-to-ram a couple of months ago.
> Replace it with suspend-to-disk at your own will:

This also is offensive, because the current swsusp _does_ work for many
people.  Actually I've recently tried a couple of various machines on which
it "just works", so I will not replace suspend-to-ram with suspend-to-disk
below, sorry.

Moreover, if it doesn't and the problem is reported, we do our best to trace
it and fix it, but sometimes we just can't do this without access to the
hardware in question.

> "The fact that worries me is that suspend-to-ram DOES NOT WORK FOR PEOPLE. 
> I have never _ever_ met a laptop or machine of mine that "just worked". 
> I've always had to fix something, and people always end up having to do 
> something ridiculous like unlink all modules etc.
> 
> If that isn't what worries you, you're on the wrong page."

And that's very true.  For example, the suspend-to-ram doesn't fully work
on my own box and I'm not sure it ever will.  However, that's not a fault
of anyone who works on this, just broken BIOS and the lack of documentation.
This is worrisome and many people work on improving these things, but
the matter is notoriously difficult.

Greetings,
Rafael

RE: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Hua Zhong]

> I don't _blame_ drivers.  I only wanted to say this: "If 
> Nigel knows that some drivers need to be fixed and he has 
> working fixes for these drivers, he should have submitted 
> these fixes for merging instead of just keeping them in 
> suspend2".  Period.
> 
> If I know of a fix for a driver, I always do my best to make 
> sure the fix will get considered for merging at least.  The 
> problem is I'm not a driver expert and I can't provide the 
> fixes myself.

Suspend2 patch is open source. You can always take a look. Moreover, if someone claims suspend2 isn't ready for merge, or the
patches Nigal has submitted aren't up to standards, one would guess he'd have done so already. So I don't understand what the above
means. Have you asked Nigal whether he had any driver fixes? If you guys are really working together, isn't it very easy to do?

> And that's very true.  For example, the suspend-to-ram 
> doesn't fully work on my own box and I'm not sure it ever 
> will.  However, that's not a fault of anyone who works on 
> this, just broken BIOS and the lack of documentation.
> This is worrisome and many people work on improving these 
> things, but the matter is notoriously difficult.

I'm not exactly an expert, but I don't think suspend-to-ram is more difficult than suspend-to-disk (probably quite the contrary),
and there are a lot in common.

I am sorry that you find some of the comments offensive, but there isn't really anything personal. It's merely a reflection of the
frustration from linux users wrt suspend OVER THE YEARS. I know you guys are hard working, but in the end it's a top-quality suspend
that counts, and people's patience has been wearing out, especially when there has been an out-of-tree implementation available for
a long time already. Everyone wants to see the current maintainers take a more humble and proactive attitude when working with Nigal
instead of just dismissing his "bad design" and bashing his patch quality. It's so easy to block someone's initiative than making it
better.

Hua

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Pavel Machek]

On Sun 2006-07-30 15:25:49, Hua Zhong wrote:
> > I don't _blame_ drivers.  I only wanted to say this: "If 
> > Nigel knows that some drivers need to be fixed and he has 
> > working fixes for these drivers, he should have submitted 
> > these fixes for merging instead of just keeping them in 
> > suspend2".  Period.
> > 
> > If I know of a fix for a driver, I always do my best to make 
> > sure the fix will get considered for merging at least.  The 
> > problem is I'm not a driver expert and I can't provide the 
> > fixes myself.
> 
> 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.

> I'm not exactly an expert, but I don't think suspend-to-ram is more
> difficult than suspend-to-disk (probably quite the contrary), and
> there are a lot in common.

As you said, you do not know what you are talking about.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Bill Davidsen]

Pavel Machek wrote:

>On Sun 2006-07-30 15:25:49, Hua Zhong wrote:
>  
>
>>>I don't _blame_ drivers.  I only wanted to say this: "If 
>>>Nigel knows that some drivers need to be fixed and he has 
>>>working fixes for these drivers, he should have submitted 
>>>these fixes for merging instead of just keeping them in 
>>>suspend2".  Period.
>>>
>>>If I know of a fix for a driver, I always do my best to make 
>>>sure the fix will get considered for merging at least.  The 
>>>problem is I'm not a driver expert and I can't provide the 
>>>fixes myself.
>>>      
>>>
>>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.
>  
>
But you can't get the patch accepted, that's issue causing all this 
discussion.

>>Moreover, if someone claims suspend2 isn't ready for merge, or the
>>    
>>
>
>Moreover, if someone claims swsusp is broken, they should attach
>bugzilla id.
>
>  
>
>>I'm not exactly an expert, but I don't think suspend-to-ram is more
>>difficult than suspend-to-disk (probably quite the contrary), and
>>there are a lot in common.
>>    
>>
>
>As you said, you do not know what you are talking about.
>
>  
>
That's why people are frustrated. You blow off anyone who tells you the 
code doesn't work. Do you really think Linus doesn't know what he's 
talking about when he reported that it didn't work for him? Hua Zhong 
being "Not an expert" is not the same as not knowing what he's talking 
about.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Pavel Machek]

Hi!

> >>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.

> But you can't get the patch accepted, that's issue causing all this 
> discussion.

If you send me a reasonably-sized patch, that actually fixes
something, I'm likely to apply it. If you send me 14K line monster...

> >>I'm not exactly an expert, but I don't think suspend-to-ram is more
> >>difficult than suspend-to-disk (probably quite the contrary), and
> >>there are a lot in common.
> >
> >As you said, you do not know what you are talking about.
> >
> That's why people are frustrated. You blow off anyone who tells you the 
> code doesn't work. Do you really think Linus doesn't know what he's 
> talking about when he reported that it didn't work for him? Hua Zhong 
> being "Not an expert" is not the same as not knowing what he's 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.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Hua Zhong]

> > 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

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Rafael J. Wysocki]

On Monday 31 July 2006 20:55, Hua Zhong wrote:
]--snip--[
> > 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

The "_should_" is important here, IMHO.

I think the problems that we have with getting STR to work on many machines
reflect the situation in which we are with respect to the hardware.  From the
programming point of view it's easy, because if you know how to handle the
hardware, it doesn't take a lot to get it right.  Still, you need to _know_,
and we're talking of things that are hardly documented and require hours of
trial-and-error to figure out.  Usually, it can only be done by someone who
(a) has access to the hardware in question, (b) has a lot of time, (c)  is
_very_ determined to make the suspend and resume work on this particular
 device, because these things are notoriously difficult to debug,  and (d),
ideally, knows how to write Linux device drivers.  If you own an "exotic"
notebook, there's practically no chance to find someone like that who owns
one too.

Moreover, even if there are some hardware-related fixes in the wild, we can't
just throw them at Andrew to merge, because some kernel developers may
think they are not the right fixes.  Each fix, before it gets merged, if ever,
has to be reviewed by the appropriate driver maintainers and people who know
how the related subsystems work.  If the fix gets rejected, we can't help it.

For example, we've recently received a fix for a resume-related problem
on some IDE chipsets (AMD and NVidia ones), but it has been vetoed by
Alan Cox.  The Alan's arguments are reasonable and everyone seems to agree
that it should be done differently, but the net result, for now, is the
problem remains - officially - unfixed (see
http://www.ussg.iu.edu/hypermail/linux/kernel/0607.3/1607.html).

However, Nigel maintains his patch in separation with the mainline kernel
and he can include fixes like that into it just fine.  He can include whatever
he likes, as long as it works, but we just can't do that.  You can say he has
more freedom, because he doesn't have to take the other people's opinions
into consideration, so he can make suspend2 work on a greater number of
systems more easily.  Yet, he faces the other people's opinions about the
things that are in suspend2 whenever he submits it for merging.  In other
words, the same things that make suspend2 work on machines on which
swsusp doesn't may also render it _very_ difficult to merge (eg. if Nigel had
decided to include the patch vetoed by Alan into suspend2, the Alan's NAK
would have applied to suspend2 as a whole).

Generally speaking suspend2 is a collection of many different solutions, some
of them being more or less questionable, in many different areas which should
not be considered all at once.  There should be a separate patch for each of
them, submitted and discussed on its own.  Moreover,  some of these solutions
may be considered as not the right ones and some patches may get rejected,
which may affect the next patches etc.  Still, this is the way in which the
kernel is developed and we have no other way to follow.

Greetings,
Rafael

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Pavel Machek]

On Mon 2006-07-31 11:55:58, Hua Zhong wrote:
> > > 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.

I have taken a look at suspend2 and decided I did not like it. (see
archives). If you think parts of suspend2 are useful (== fix problem
on hardware you have), separate them and submit them.

If you want to claim that swsusp is broken, you should attach bugzilla
ids. Anything else is unhelpful.

I'm maintainer, but that does not mean that I have every possible
notebook on earth.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Bill Davidsen]

Hua Zhong wrote:
>> Moreover, if the swsusp's resume doesn't work for you and 
>> suspend2's resume does, this probably means that suspend2 
>> contains some driver fixes that haven't been submitted for merging.
> 
> This statement worries me for several reasons.
> 
> First, I've seen repeatedly blame for "drivers". People might buy it if there was not a working suspend2. I never saw Nigal blame
> drivers; instead he makes sure to provide working code. In the end, users want a working suspend, and that's what counts.
> 
> Second, if the current swsusp maintainers have genuine interest for the users (not just "it works on my machine"), I would think
> they'd have taken a serious look at why suspend2 has a higher success rate. But from the above comment, you are not even sure why
> that is, and could only speculate "this probably means (drivers)". I could hardly be convinced that the current maintainers have
> been trying to work with Nigal to improve Linux suspend.
> 
> At last, "maintainer" is not just a title or a feeling of superiority, it's a responsibility of providing a great system to the
> users. I'll just quote Linus when he was flaming suspend-to-ram a couple of months ago. Replace it with suspend-to-disk at your own
> will:
> 
> "The fact that worries me is that suspend-to-ram DOES NOT WORK FOR PEOPLE. 
> I have never _ever_ met a laptop or machine of mine that "just worked". 
> I've always had to fix something, and people always end up having to do 
> something ridiculous like unlink all modules etc.
> 
> If that isn't what worries you, you're on the wrong page."
> 
> http://article.gmane.org/gmane.linux.power-management.general/2105

That's the way I feel, I'm glad someone who can't be ignored feels the 
same way. There is always a reason why the working version can't be put 
in mainline, there's always a reason why it doesn't work on my machines 
but I'm assured that it works on {someone}'s machine so I must have a 
bad {bios|setup|partition table|attitude}.

-- 
Bill Davidsen <davidsen@tmr.com>
   Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Pavel Machek]

Hi!

> That's the way I feel, I'm glad someone who can't be ignored feels the 
> same way. There is always a reason why the working version can't be put 
> in mainline, there's always a reason why it doesn't work on my machines 
> but I'm assured that it works on {someone}'s machine so I must have a 
> bad {bios|setup|partition table|attitude}.

Do you have bugzilla # or are you just flaming? Please test 2.6.18-rc2.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Pavel Machek]

Hi!

> > Moreover, if the swsusp's resume doesn't work for you and 
> > suspend2's resume does, this probably means that suspend2 
> > contains some driver fixes that haven't been submitted for merging.
> 
> This statement worries me for several reasons.
> 
> First, I've seen repeatedly blame for "drivers". People might buy it if there was not a working suspend2. I never saw Nigal blame
> drivers; instead he makes sure to provide working code. In the end, users want a working suspend, and that's what counts.
>

You seem to be claiming that swsusp is broken, but I do not remember
any bugreport from you. So... either provide bugzilla #, or stop
spreading FUD.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Bill Davidsen]

Rafael J. Wysocki wrote:

>On Saturday 29 July 2006 21:23, Bill Davidsen wrote:
>  
>
>>Pavel Machek wrote:
>>    
>>
>>>On Fri 28-07-06 01:22:49, Olivier Galibert wrote:
>>>      
>>>
>>>>On Thu, Jul 27, 2006 at 11:42:25PM +0200, Pavel Machek wrote:
>>>>        
>>>>
>>>>>So we have 1 submission for review in 11/2004 and 1 submission for -mm
>>>>>merge in 2006, right?
>>>>>          
>>>>>
>>>>Wrong.  I gave a list of dates at the beginning of the month, do you
>>>>think I threw dice to get them?
>>>>
>>>>And could you explain, as suspend maintainer for the linux kernel, how
>>>>come code submitted for the first time two years ago and with a much
>>>>better track record than the in-kernel one is still not in?
>>>>        
>>>>
>>>Because Nigel has too much of code to start with, and refuses to fix
>>>his design because it would invalidate all the stabilization work.
>>>      
>>>
>>Why should he invalidate his stabilization work, and what's in need of 
>>fixing? The suspend in the kernel is great, but suspend2 includes both 
>>suspend and working resume code as well.
>>    
>>
>>>Plus Nigel did not do very good job with submitting those patches.
>>>      
>>>
>>They apply, they work. What's not very good about that? Is this being 
>>blocked because of a spelling error, or did he mess up the indenting on 
>>"signed off by" or what? I realize you may have something other than the 
>>download version, but it's been years now.
>>
>>I would like to see the working suspend (suspend2) in the kernel, and 
>>users wanting to debug the resume stuff currently in the kernel could 
>>get it under EXPERIMENTAL or some such.
>>    
>>
>
>You probably don't realize how offensive this is.
>
>Actually some people have been working really hard to make the in-kernel
>code work and you could just respect that.
>  
>
By respect I take it you mean "don't call attention to the fact that it 
doesn't work for many people?"

>Now, please note the swsusp resume code works for me 100% of the time
>and I know of many people who use it without any problems.  Also I know of
>some people for whom suspend2 doesn't work.  Please take this into
>consideration.
>  
>
That's exactly the answer I've been getting for saveral years, "it works 
for me and my friends," and "try x.y.z release."

>Moreover, if the swsusp's resume doesn't work for you and suspend2's resume
>does, this probably means that suspend2 contains some driver fixes that
>haven't been submitted for merging.
>
That's been addressed by other people, but the suspend2 patch has been 
submitted multiple times, if there is some driver fix it certainly has 
been submitted, just not accepted.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Rafael J. Wysocki]

On Sunday 30 July 2006 14:57, Bill Davidsen wrote:
> Rafael J. Wysocki wrote:
> 
> >On Saturday 29 July 2006 21:23, Bill Davidsen wrote:
> >  
> >
> >>Pavel Machek wrote:
> >>    
> >>
> >>>On Fri 28-07-06 01:22:49, Olivier Galibert wrote:
> >>>      
> >>>
> >>>>On Thu, Jul 27, 2006 at 11:42:25PM +0200, Pavel Machek wrote:
> >>>>        
> >>>>
> >>>>>So we have 1 submission for review in 11/2004 and 1 submission for -mm
> >>>>>merge in 2006, right?
> >>>>>          
> >>>>>
> >>>>Wrong.  I gave a list of dates at the beginning of the month, do you
> >>>>think I threw dice to get them?
> >>>>
> >>>>And could you explain, as suspend maintainer for the linux kernel, how
> >>>>come code submitted for the first time two years ago and with a much
> >>>>better track record than the in-kernel one is still not in?
> >>>>        
> >>>>
> >>>Because Nigel has too much of code to start with, and refuses to fix
> >>>his design because it would invalidate all the stabilization work.
> >>>      
> >>>
> >>Why should he invalidate his stabilization work, and what's in need of 
> >>fixing? The suspend in the kernel is great, but suspend2 includes both 
> >>suspend and working resume code as well.
> >>    
> >>
> >>>Plus Nigel did not do very good job with submitting those patches.
> >>>      
> >>>
> >>They apply, they work. What's not very good about that? Is this being 
> >>blocked because of a spelling error, or did he mess up the indenting on 
> >>"signed off by" or what? I realize you may have something other than the 
> >>download version, but it's been years now.
> >>
> >>I would like to see the working suspend (suspend2) in the kernel, and 
> >>users wanting to debug the resume stuff currently in the kernel could 
> >>get it under EXPERIMENTAL or some such.
> >>
> >You probably don't realize how offensive this is.
> >
> >Actually some people have been working really hard to make the in-kernel
> >code work and you could just respect that.
> >
> By respect I take it you mean "don't call attention to the fact that it 
> doesn't work for many people?"

Sorry, you won't get anywhere by insulting people.  If you want to call
attention to a problem, please file a bug report.

Greetings,
Rafael

Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

[Pavel Machek]

Hi!

> >Plus Nigel did not do very good job with submitting those patches.
> 
> They apply, they work. What's not very good about that? Is this being 
> blocked because of a spelling error, or did he mess up the indenting on 
> "signed off by" or what? I realize you may have something other than the 
> download version, but it's been years now.

Ask Nigel or search the archives. I will not repeat myself again.

> I would like to see the working suspend (suspend2) in the kernel,

Great. Help with debugging. Alternatively, help Nigel with fixing
design problems and separating patches for merge -- that should keep
you busy and stop you from trolling on the lists.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html