lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 30 Jul 2006 00:54:18 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	"Hua Zhong" <hzhong@...il.com>
Cc:	"'Bill Davidsen'" <davidsen@....com>,
	"'Pavel Machek'" <pavel@....cz>,
	"'Kernel Mailing List'" <linux-kernel@...r.kernel.org>
Subject: Re: suspend2 merge history [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ