Re: [ 00/10] [Suspend2] Modules support.

[Nigel Cunningham <nigel@suspend2.net>]

[-- Attachment #1: Type: text/plain, Size: 3772 bytes --]

Hi Andrew et al.

On Friday 03 February 2006 07:27, Andrew Morton wrote:
> Pavel Machek <pavel@ucw.cz> wrote:
> > > I don't want to argue Pavel. I want to give users the best suspend to
> > > disk implementation they can get. If you want to argue, you can do so
> > > with
> >
> > I want to create best suspen that can be still merged into kernel; I
> > guess thats the difference. Anyway I believe that most of suspend
> > should be done in userspace -- most of it can. But I guess you need to
> > hear it from Linus/Andrew, so...
>
> You're unlikely to hear anything dispositive from either of us on this.
> You three guys know far more than us about suspend, so it would be silly
> for us to be making the technical decisions.  When cornered, we're more
> likely to come out with general kernel platitudes such as "doing it in
> userspace:good" and "crashing the kernel:bad" and "incremental development
> with early merges:good" and "mucking up the kernel source:bad".
>
> What we hope and expect is that you'll come up with an agreed path in
> accordance with general kernel coding and development principles.  Linus
> and I don't want to have to make tiebreak decisions - if we have to do
> that, the system has failed.
>
> Random thoughts:
>
> - swsusp has been a multi-year ongoing source of churn and bug reports.
>   It hasn't been a big success and we have a way to go yet.
>
> - People seem to be doing too much development on the swsusp core and not
>   enough development out where the actual problems are: drivers which don't
>   suspend and resume correctly.
>
> - suspend2 is at a disadvantage because swsusp was merged first.  If
>   neither of the solutions had been merged and if we were evaluating them
>   side-by-side, suspend2 would have a much better chance.  This is a
>   problem.
>
> - If you want my cheerfully uninformed opinion, we should toss both of
>   them out and implement suspend3, which is based on the kexec/kdump
>   infrastructure.  There's so much duplication of intent here that it's not
>   funny.  And having them separate like this weakens both in the area where
>   the real problems are: drivers.
>
> - Justifying the inclusion of a feature by the appearance and usefulness
>   of the end result doesn't really work in this world.  There are numerous
>   unmerged kernel features out there which work well and look great.  But
>   we will look under the hood, and that's when problems start.
>
>
> So, as promised, there's nothing useful here.  What we'd most like to see
> is for Nigel to start working on in-kernel swsusp, merging up the good bits
> from suspend2 in some evolutionary incremental manner under which the
> kernel continually improves.  If, at the end of the day, that ends up with
> us having a complete implementation of suspend2, well, Mission
> Accomplished?

Thanks for the reply. You're right. It doesn't help at all :)

Well, actually it does.

It reminds me why I started working on this in the first place. It wasn't 
because I wanted to be a big shot kernel developer or the like, or have my 
name in the kernel credits. It was because I wanted to use the code.

So, given that I'm perfectly willing to send Pavel patches, but he's not 
willing to take them, I guess I the best thing I can do is to just let Pavel 
have his way, give up on the concept of merging Suspend2 and maintain it out 
of tree. When Pavel and Rafael get swsusp up to scratch, I can stop doing 
that and just use their version.

Well, that's what I think at the moment. Let's see how things progress.

Nigel
-- 
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net                IRC: #suspend2 on Freenode

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]