[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20080714054351.GB20258@elf.ucw.cz>
Date: Mon, 14 Jul 2008 07:43:52 +0200
From: Pavel Machek <pavel@...e.cz>
To: David Fries <david@...es.net>
Cc: Michael Tokarev <mjt@....msk.ru>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: hibernate/suspend-to-disk: to turn power or not?
On Sun 2008-07-13 18:26:36, David Fries wrote:
> On Thu, Jan 31, 2008 at 03:40:30PM +0100, Pavel Machek wrote:
> > > Back to the original question and a proposed solution.
> > >
> > > I'm looking at the uswsusp source (while the kernel compiles),
> > > and have a question here. Is it possible to call some external
> > > application (typically a shell script) to do the final work after
> > > when the image has been written? I mean in principle - I
> > > understand there are some limitations here, but I don't know
> > > which exactly.
> >
> > No, you can't exec() anything. That would write mtime back to disk and
> > cause badness.
>
> SysRq-U remounts the disks readonly. Why not make the disks readonly
> once the kernel state is in swap, why not let any program run and give
> an error to writes?
IIRC sysrq-U does not contain all the locking that's neccessary to
make it completely safe. OTOH, it tends to work...
> I know, long dead thread, but I too would like to tell the UPS to turn
> off once the system state is resting safely in swap. Currently my
> modified apcupsd scripts tell the UPS to turn off, then tells the
> kernel to hibernate, and hopes the kernel finishes in time. I would
> much rather do things the other way, but `echo disk > /sys/power/disk`
> doesn't return until power is back on if everything goes well.
If you use s2disk, you can execute C code at the point you want...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists