Hi!
> > > Doesn't that imply your fix is broken to begin with?
> >
> > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > overdesign to me, OTOH if you do the work it is okay with me.
>
> You broke the design. S3 support was developed long before swsusp was in
> the kernel, and completely indpendent of it. It should have remained that
> way.
>
> S3 support is a subset of what is need for S4 support.
That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
but not for S4. Big part of driver support is only needed for S3.
> swsusp is an implementation of S4 support. In theory, there could be
> multiple implementations that all use the same core (saving/restoring
> state).
There were patches for S4bios floating around, but it never really
worked, IIRC.
> There could also be different power management schemes that use swsusp as
> an implementation for suspend-to-disk. But, that's another tangent.
>
> CONFIG_ACPI_SLEEP should give you S3 support, and the ACPI side of S4
> support.
What's ACPI side of S4 good for when you can not do S4?
> The comment in the config option should tell the user that they
> must choose a suspend implementation (e.g. CONFIG_SUSPEND, which should
> prolly be CONFIG_SWAP_SUSPEND) in order to get complete S4 support. (The
> ACPI side can make an empty call to swsusp if no implementation is
> selected).
S3 needs process stopper from kernel/suspend.c. I did not want to have
#ifdefs all over suspend.c...
> Some time ago, I made a BK repo for suspend support. I axed it, since no
> one ever used it. But, it's back again, and I'll be integrating your
> patches and try to dedicate a few extra cycles to resolving some of the
> issues. I'll send an announcement to the list once I've integrated your
> patches.
I probably will not persuade you to make it CVS, right? [Sorry, I'm
not going to touch bitkeeper.]
Pavel
-- Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:24 EST