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 [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]
