On Sat, 28 Jul 2007, Adrian Bunk wrote: > > The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, so > what about something like the patch below? Yeah, this looks reasonable. May I suggest another level of indirection, though: > +config SUSPEND_SMP_POSSIBLE > + bool > + depends on (X86 && !X86_VOYAGER) || (PPC64 && (PPC_PSERIES || PPC_PMAC)) > + depends on SMP > + default y How about making this a bit more split up, and do it as # SMP suspend is possible on .. config SUSPEND_SMP_POSSIBLE bool depends on (X86 && !X86_VOYAGER) || (PPC64 && (PPC_PSERIES || PPC_PMAC)) default y # UP suspend is possible on .. config SUSPEND_UP_POSSIBLE bool depends on X86 || PPC64_SWSUSP || FRV || PPC32 default y # Can we suspend? config SUSPEND_POSSIBLE bool depends on (SMP && SUSPEND_SMP_POSSIBLE) || (SUSPEND_UP_POSSIBLE && !SMP) default y and then we have just a config SOFTWARE_SUSPEND bool "Software Suspend (Hibernation)" depends on PM && SWAP depends on SUSPEND_POSSIBLE config SUSPEND_SMP bool depends on SOFTWARE_SUSPEND && SMP select HOTPLUG_CPU default y and now each of the config options looks pretty simple and describe one thing. [ For extra bonus points: the SUSPEND_POSSIBLE thing is still pretty complicated, and it might actually be a better idea to make it a per-arch config option, and just make the x86/arch say config SUSPEND_POSSIBLE bool depends on !(X86_VOYAGER && SMP) default y instead: since SUSPEND_POSSIBLE is always true on x86 regardless of SMP or not, just not on X86_VOYAGER. Then, each architecture can have its own private rules for whether that architecture has SUSPEND_POSSIBLE or not, so on ppc, it might look like config SUSPEND_POSSIBLE bool depends on (PPC64 && (PPC_PSERIES || PPC_PMAC)) || PPC_SWSUSP bool y or something, but the point is, now the complexity is a per-architecture thing, so other architectures simply don't have to care any more! ] And the user only ever sees one single question: the one for "SOFTWARE_SUSPEND". All the others would directly flow either from the architecture choice, or from that. Anybody willing to rewrite it that way? Linus - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
