> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
