Messages in this thread | | | Date | Sun, 12 Feb 2006 10:51:29 +0200 | From | Alon Bar-Lev <> | Subject | Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) |
| |
Kyle Moffett wrote: > On Feb 11, 2006, at 11:36, Jan Merka wrote:
>> I strongly disagree. I got suspend-to-RAM to work but its utility is >> seriously limited by battery capacity. For example, on my laptop (Sony >> VGN-B100B) with 1.5GB of RAM, a fully charged battery is drained in >> about 18 hours if the laptop was suspended to RAM. > > Ick, that's kind of sucky hardware then. My PowerBook with 1GB RAM > easily gets a week of sleep time off a fully charged battery; I don't > think I've rebooted it _once_ in the last 2 months, I just leave it > sleeping in my bag the whole time. Sony must be doing something wrong, > because there's easily enough power in a single battery to keep RAM > refreshed for a _long_ time. > >> Yes, for a few hours suspend-to-RAM is convenient but suspend-to-disk >> is _reliable_ and _safe_. > > As to the safety issue, I have my Apple Powerbook configured to suspend > to RAM, and if it gets critically low on battery I have the firmware set > to resume it automatically and my scripts shut it down so I don't lose > data. Suspend-to-RAM when implemented properly _is_ reliable and safe, > but it seems like a lot of hardware manufacturers get it wrong. >
Hello,
I don't understand how a fundamental (good) debate of how suspend to disk should be implemented in kernel, changed into this one.
I don't care what Linus said... Suspend-to-disk is more complicated than suspend-to-RAM. It is more complicated since it provides more features. Suspend-to-RAM only stores state, where Suspend-to-disk need to store the state somewhere thus changing the initial state.
There is a long list of features available at http://wiki.suspend2.net/FeatureUserRegister, which cannot be provided using suspend-to-RAM, examples: 1. Store state on files - this allow you to resume your machine into a different OS. 2. Encrypt state - this allow you to be sure that your data is stored encrypted. (Yes... You can encrypt the memory... but then you need a whole initramfs clone in order to allow the user to specify how he want to encrypt/decrypt). 3. Network resume - this allow you to resume a network machine (Not implemented yet, but cannot be done if suspend-to-RAM is the sole implementation). 4. Support desktops/servers - this allow you to suspend/resume hardware that is not designed to sleep, in order to minimize downtime on power failure.
And another fact: Suspend-to-RAM implementation can be derived form suspend-to-disk but not the other way around.
So let's invert the initial "fact"... Suspend-to-RAM is basically for people that don't need the full functionality of suspend-to-disk, after I got suspend-to-disk to work reliably here (suspend2), I *NEVER* use suspend-to-RAM.
Best Regards, Alon Bar-Lev. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |