Re: swsusp: revert to 2.6.0-test3 state

[Pavel Machek]

Hi!


> > No, you have to understand that I don't want to call software_suspend() at 
> > all. You've made the choice not to accept the swsusp changes, so we're 
> > forking the code. We will have competing implementations of 
> > suspend-to-disk in the kernel. 
> > 
> > You may keep the interfaces that you had to reach software_suspend(), but
> > you may not modify the semantics of my code to call it. At some point, you 
> > may choose to add hooks to swsusp that abide by the calling semantics of 
> > the PM core, so that you may use the same infrastructure.
> > 
> > Please send a patch that only removes the calls to swsusp_* from 
> > pm_{suspend,resume}. That would be a minimal patch. 
> 
> Where does this put me? I'm finishing off 1.1 for 2.4 and have a port to
> 2.6 in process. I want to get it merged, but how do I go about that now?
> 
> For the record, it's worth merging, I believe. It has a fully year of
> extensive testing, support for saving a full (as opposed to minimal)
> image of RAM, support for highmem, swap files, full asynchronous I/O,
> aborting cleanly from errors, user tuning and a nice interface. I don't
> want to see it thrown away, but neither do I want to have a third
> option!

It puts you in a better position, AFAICS. When code is rewritten
anyway, "don't fix it if it aint broken" is not so important any
more -- good for you.

I still hope to avoid two software suspends in 2.6.X.

								Pavel

-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/