Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

Hi!

> >> And another fact: Suspend-to-RAM implementation can be derived form
> >> suspend-to-disk but not the other way around.
> > 
> > No, the two are _entirely_ independent.  Suspend-to-RAM does not need to
> > copy memory at all, whereas suspend-to-disk requires it.  That very fact
> > means that suspend-to-RAM is orders of magnitude faster than
> > suspend-to-disk could ever be, especially as RAM gets exponentially larger.
> 
> Well... I see you already planned the implementation and
> have all figured out...
> But the fact is that suspend-to-RAM can be implemented by
> suspend-to-disk without actually store the memory to
> external device...

No, it can not. See Doc*/power/video.txt . And there are more such problems.

> Again... This is a matter of implementation... I believe
> that one complete suspend implementation can suite both disk
> and RAM... The only difference is if you write the state to
> external storage, and how you play with APM. So there is a

How you play with ACPI/hw is major issue. Look at code to learn what you are talking
about. (and nobody uses APM today). 

> Let's see what happened so far:
> 
> First we had swsusp... For many people it did not work, so

...no; for many people it was too slow and not nice enough...

> Suspend2 was developed, but was not merged mainly because it
> had too many UI components in-kernel.

...and because Nigel did not care about mainline for a *long* time.

> Now, you come with a different solution (virtualization), so
> let's delay suspend feature for how long? At least two years?

Virtualization is separate topic. It could be used for s-t-disk,
but it is quite heavy solution, and not likely to be usable for s-t-disk for
4+ years.

> We need (and can get) suspend to work *NOW*, laptops are
> being more and more common... People expect to have this
> ability in a modern operating system, they don't care if it
> is implemented in kernel or in user-space, they also don't
> care if you change it along the way... And if in the future
> Linux will be pure virtual machine, all will be happy....
> And use it... But please consider offering a working
> solution *NOW*.

We have working solution *NOW*. It is called swsusp. If it does not work for you,
report it using bugzilla.kernel.org.

If you want something nicer/faster, help with suspend.sf.net.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

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