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

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]

Message-ID: <00c801c6b427$20d545d0$0200a8c0@nuitysystems.com>
Date:	Sun, 30 Jul 2006 15:25:49 -0700
From:	"Hua Zhong" <hzhong@...il.com>
To:	"'Rafael J. Wysocki'" <rjw@...k.pl>
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]

> 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

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