Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > > > > Frankly, I'd rather be working on improving drivers and helping
> > > > > implement the run-time power management than working on getting
> > > > > Suspend2 merged.
> > > Developmentwise, I think it's finished - unless I want to go off in a new
> >
> > I'd say that suspend2 already done its job -- forced me to do
> > uswsusp. I do not think it is mergeable without major refactoring.
> 
> I'm sorry, Pavel, but it if uswsusp is going to be an acceptable replacement 
> for Suspend2, it has to actually have the features suspend2 has implemented, 
> not just have the promise of them appearing at some stage. Rafael is doing 
> admirable work in that direction, but he's not there yet.

If you trust Rafael can get the features you want... please help
him. It should be easier than another suspend2 resubmit...

> > > > As far as the support for ordinary files, swap files, etc. is
> > > > concerned, there's nothing to worry about.  It's comming.
> > >
> > > Great. It will be good to see that. Do you have some way around bmapping
> > > the files?
> >
> > You mean "some way to go without bmapping" or "did you get bmapping to
> > work" ?
> 
> Some way to go without bmapping. I'm assuming you're going to have to add some 
> kernel code to at least do the bmapping. By the way, watch out for block 
> sizes. Especially with XFS. It's the best test of whether your code is right 
> because the blocksize XFS uses might not be the same as the underlying block 
> device's blocksize.

Why is bmapping evil?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html