Re: Back to the future.
From: Bill Davidsen
Date: Sat Apr 28 2007 - 15:09:40 EST
Nigel Cunningham wrote:
Please, go apply that logic elsewhere, then cut out (or at least stopI think to some extent that's part of the problem. Consider for a moment
that a /dev/hibernate would be required, and that it must be (a) a disk,
or (b) a partition, or (c) other devices in the future, like an nbd, USB
flash or DVD.
adding) support for users with less common needs in other areas. I fully
acknowledge that most users have only one place to store their image and
it's a swap device. But that doesn't mean one size fits all.
Don't have a device like that, then can't hibernate. Stop trying to be
smart and use swap for two different things. Stop trying to have an
interface between user space and kernel which does things not required
to preserve the system. A progress indicator is not needed, power off is
my progress indicator, and should be the sole valid end of a hibernate.
A full image implies that you need to figure out what's not going to
change while you're writing it and save that separately. At the moment,
I'm treating most of the LRU contents as that list. If we're going to
start trying to let every man and his dog run while we're trying to
snapshot the system, that's not going to work anymore - or the logic
will get a lot more complicated.
Sorry. I never thought I'd say this, but I think you're being naive
about how simple the process of snapshotting a system is.
Hibernate is useful to avoid complex boot, it's useful as the UPS gets
tired, and putting features in the process beyond saving the snap
(possibly compressed and/or encrypted) just adds complexity. Put it all
in the kernel and use /sys/power/state as the user interface. Stop
oversolving the problem.
No, that doesn't avoid other hard issues, but for the most part suspend2
has addressed them.
Bill Davidsen <davidsen@xxxxxxx>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
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/