Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)
From: Rafael J. Wysocki
Date: Thu Apr 26 2007 - 14:36:51 EST
On Thursday, 26 April 2007 18:31, Johannes Berg wrote:
> On Thu, 2007-04-26 at 13:30 +0200, Pavel Machek wrote:
> > > From looking at pm_ops which I was recently working with a lot, it seems
> > > that it was designed by somebody who was reading the ACPI documentation
> > > and was otherwise pretty clueless, even at that level std tries to look
> > > like suspend. IMHO that is one of the first things that should be ripped
> > > out, no pm_ops for STD, it's a pain to work with.
> > That code goes back to Patrick, AFAICT. (And yes, ACPI S3 and ACPI S4
> > low-level enter is pretty similar).
> > Patches would be welcome
> That was easier than I thought. This applies on top of a patch that
> makes kernel/power/user.c optional since I had no idea how to fix it,
> problems I see:
> * it surfaces kernel implementation details about pm_ops and thus makes
> the whole thing very fragile
Can you elaborate?
> * it has yet another interface (yuck) to determine whether to reboot,
> shut down etc, doesn't use /sys/power/disk
Yes. In fact it was meant as a replacement for /sys/power/disk at one point.
> * I generally had no idea wtf it is doing in some places
I could have told you if you had asked. :-)
> Anyway, this patch is only compile tested, it
> * introduces include/linux/hibernate.h with hibernate_ops and
> a new hibernate() function to hibernate the system
Do we need hibernate_ops at all? There's only one user anyway and I'm not
sure there will be more of them in the future.
> * rips apart a lot of the suspend code and puts it back together using
> the hibernate_ops
> * switches ACPI to hibernate_ops (the only user of pm_ops.pm_disk_mode)
> * might apply/compile against -mm, I have all my and some of Rafael's
> suspend/hibernate work in my tree.
> * breaks user suspend as I noted above
> * is incomplete, somewhere pm_suspend_disk() is still defined iirc
I think I can fix it up, just give me some time.
The idea is good, I think we should do someting like this.
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/