Re: hibernate/suspend-to-disk: to turn power or not?

[Michael Tokarev]

Pavel Machek wrote:
[]
>> 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.

Now that's.. interesting.

s2disk writes to a swap device/file, which should update
mtime of this device node/file.  Isn't it something which
also causes the same badness?

Also, if the only concern is mtime update, what's really
wrong with it?  I mean, regardless of whether such update
will finally hit the disk or not, there's not much difference
really - it updates just mtime field, and there should be
no harm in that.  Unless such update first goes to a
journal (in a journalling filesystem) - which DOES modify
some on-disk structures.

>> it typically involves writing/reading something to/from
>> a given serial port (/dev/ttySxx), or to an USB device,

> Create libups.so, and link s2disk to it?

And what's the difference here again?  We'll open a serial
port and write something to it - which, again, will update
mtime of that device node.  Unless the said node is on a
tmpfs, exactly the same badness will happen.  Not all the
world is udev, after all.

So I don't get the reason why we can't exec something here,
still.  (And, for example, call splashy commands as external
processes, instead of linking all this cruft into s2disk and
resume.)

What I'm thinking about here is - s2ram mlock()s its memory.
If it will fork/exec something, that something will obviously
NOT be locked like that.  Is it of some concern?  Probably
not, because that something will be executed after we've
taken the snapshot.

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