Re: [PATCH] [3/48] Suspend2 2.1.9.8 for 2.6.12:301-proc-acpi-sleep-activate-hook.patch

[Nigel Cunningham]

Hi.

On Tue, 2005-07-12 at 19:47, Matthew Garrett wrote:
> Nigel Cunningham <ncunningham@xxxxxxxxxxxx> wrote:
> 
> > When the user has an initrd or initramfs, they're supposed to include
> > 
> > echo > /proc/software_suspend/do_resume
> 
> This is a different interface to the one in swsusp, which is under /sys.
> Do we really need to keep multiple interfaces to the same functionality?

We already have that - the reboot handler, acpi S4 support and the sysfs
interface. This should have been asked when sysfs was added :>. For the
sake of backwards compatibility for current suspend2 users, it should
stay for a while at least. The other thing here is that there is much
more to /proc/software_suspend than do_resume.

> > at the point in their initrd where drivers needed for accessing the
> > image, encryption keys and so on have been set up, but the root fs has
> > not yet been mounted. If they don't do that, we should scream loudly,
> > because mounting the root fs (even read only) will replay the journal,
> > making the image not match what is on disk. This in turn can and
> > probably will result in hard disk corruption if they echo to do_resume
> > from say /etc/rc.d/rc.sysinit.
> 
> In general, the kernel does very little to prevent users from shooting
> themselves in the foot (or even chainsawing off their arms). We can do
> these checks in userspace rather than adding more kernel code.

Just because the kernel does very little, that doesn't mean it should.
Particularly for something like suspend to disk, where it's not just a
matter of an oops but of potential hard disk corruption, this is
important.

If I could do it in userspace, I would. The trouble is, the userspace
app may not be there to tell the user what is happening, and this might
be part of the problem.

Regards,

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened. 

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