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

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]

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

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

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

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

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]

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

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

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

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

[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

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]

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

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

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

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

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

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

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