linux-kernel - Re: [2.6 patch] let SUSPEND select HOTPLUG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.0.999.0707271545220.3442@woody.linux-foundation.org>
Date:	Fri, 27 Jul 2007 15:57:39 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Adrian Bunk <bunk@...sta.de>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Len Brown <lenb@...nel.org>,
	david@...g.hm, Andrew Morton <akpm@...ux-foundation.org>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	Pavel Machek <pavel@....cz>
Subject: Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU



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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/