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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
