lkml.org 
[lkml]   [2007]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-07-28 01:01    [W:0.022 / U:89.160 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site