Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU

[Linus Torvalds <torvalds@linux-foundation.org>]

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