Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Mon 2007-07-30 21:09:33, [EMAIL PROTECTED] wrote: > On Mon, 30 Jul 2007, Len Brown wrote: > > >On Saturday 28 July 2007 12:55, Linus Torvalds wrote: > > > >>So I think the real issue is that we allow that > >>"suspend_devices_and_enter()" code to be compiled without HOTPLUG_CPU in > >>the first place. It's not supposed to work that way. > > > >I don't see how CONFIG_HOTPLUG_CPU justifies its own existence. > >This e-mail thread would have never happened if it were simply included > >in CONFIG_SMP, always. > > > >I agree, of course, that ACPI should never have had to work-around > >this by selecting HOTPLUG_CPU. But even though it is now done at > >the right layer, I don't see why PM should have to > >be bothered with selecting HOTPLUG_CPU either -- > >it should just come with SMP. > > why do you need hotplug just becouse you have muliple cpus? if you never > have any intention of useing suspend and your hardware doesn't support > hotplugging, why should you have to include the code for it? Because otherwise we have way too many config options, and there are basically no downsides? Too many options => too little testing of each permutation... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Mon 2007-07-30 21:09:33, [EMAIL PROTECTED] wrote: On Mon, 30 Jul 2007, Len Brown wrote: On Saturday 28 July 2007 12:55, Linus Torvalds wrote: So I think the real issue is that we allow that suspend_devices_and_enter() code to be compiled without HOTPLUG_CPU in the first place. It's not supposed to work that way. I don't see how CONFIG_HOTPLUG_CPU justifies its own existence. This e-mail thread would have never happened if it were simply included in CONFIG_SMP, always. I agree, of course, that ACPI should never have had to work-around this by selecting HOTPLUG_CPU. But even though it is now done at the right layer, I don't see why PM should have to be bothered with selecting HOTPLUG_CPU either -- it should just come with SMP. why do you need hotplug just becouse you have muliple cpus? if you never have any intention of useing suspend and your hardware doesn't support hotplugging, why should you have to include the code for it? Because otherwise we have way too many config options, and there are basically no downsides? Too many options = too little testing of each permutation... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Mon, 30 Jul 2007, Len Brown wrote: On Saturday 28 July 2007 12:55, Linus Torvalds wrote: So I think the real issue is that we allow that "suspend_devices_and_enter()" code to be compiled without HOTPLUG_CPU in the first place. It's not supposed to work that way. I don't see how CONFIG_HOTPLUG_CPU justifies its own existence. This e-mail thread would have never happened if it were simply included in CONFIG_SMP, always. I agree, of course, that ACPI should never have had to work-around this by selecting HOTPLUG_CPU. But even though it is now done at the right layer, I don't see why PM should have to be bothered with selecting HOTPLUG_CPU either -- it should just come with SMP. why do you need hotplug just becouse you have muliple cpus? if you never have any intention of useing suspend and your hardware doesn't support hotplugging, why should you have to include the code for it? Dvaid Lang - 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Saturday 28 July 2007 12:55, Linus Torvalds wrote: > So I think the real issue is that we allow that > "suspend_devices_and_enter()" code to be compiled without HOTPLUG_CPU in > the first place. It's not supposed to work that way. I don't see how CONFIG_HOTPLUG_CPU justifies its own existence. This e-mail thread would have never happened if it were simply included in CONFIG_SMP, always. I agree, of course, that ACPI should never have had to work-around this by selecting HOTPLUG_CPU. But even though it is now done at the right layer, I don't see why PM should have to be bothered with selecting HOTPLUG_CPU either -- it should just come with SMP. -Len - 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Saturday 28 July 2007 12:55, Linus Torvalds wrote: So I think the real issue is that we allow that suspend_devices_and_enter() code to be compiled without HOTPLUG_CPU in the first place. It's not supposed to work that way. I don't see how CONFIG_HOTPLUG_CPU justifies its own existence. This e-mail thread would have never happened if it were simply included in CONFIG_SMP, always. I agree, of course, that ACPI should never have had to work-around this by selecting HOTPLUG_CPU. But even though it is now done at the right layer, I don't see why PM should have to be bothered with selecting HOTPLUG_CPU either -- it should just come with SMP. -Len - 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Mon, 30 Jul 2007, Len Brown wrote: On Saturday 28 July 2007 12:55, Linus Torvalds wrote: So I think the real issue is that we allow that suspend_devices_and_enter() code to be compiled without HOTPLUG_CPU in the first place. It's not supposed to work that way. I don't see how CONFIG_HOTPLUG_CPU justifies its own existence. This e-mail thread would have never happened if it were simply included in CONFIG_SMP, always. I agree, of course, that ACPI should never have had to work-around this by selecting HOTPLUG_CPU. But even though it is now done at the right layer, I don't see why PM should have to be bothered with selecting HOTPLUG_CPU either -- it should just come with SMP. why do you need hotplug just becouse you have muliple cpus? if you never have any intention of useing suspend and your hardware doesn't support hotplugging, why should you have to include the code for it? Dvaid Lang - 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Sat, 28 Jul 2007, Rafael J. Wysocki wrote: > > OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will require > quite a bit of (compilation) testing on different architectures. Sure. I'm not too worried, the fallout should be of the trivial kind. Also, mind basing it on the (independent) cleanups that Adrian already sent out. This is all intertwined.. 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Saturday, 28 July 2007 18:55, Linus Torvalds wrote: > > On Sat, 28 Jul 2007, Linus Torvalds wrote: > > > > And it's the *top*level* code that selects HOTPLUG_CPU. Through > > SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND. > > In other words, the problem seems to be that > > kernel/power/main.c: > suspend_devices_and_enter() > > does the proper "disable/enable_nonboot_cpus()", but it does so without > having enabled CPU hotplug. > > And you seem to think that it's ACPI that should enable the hotplug, even > though the code that actually needs it is _outside_ ACPI. And I think > that's wrong, and that this is a bug. > > So I think the real issue is that we allow that > "suspend_devices_and_enter()" code to be compiled without HOTPLUG_CPU in > the first place. It's not supposed to work that way. > > Of course, it may well be that other architectures can happily suspend > even with multiple CPU's active, which may be the cause of this mess. But > I really think it shouldn't be ACPI that has to select the CPU hotplug, > since it's not ACPI that _uses_ it in the first place. > > Rafael: making a config option for STR (the same way we have a config > option for hibernate), and just not allowing it on SMP without HOTPLUG_CPU > seems to be the right thing. Len is right in that we do insane things > right now (trying to STR with multiple CPU's still active), and I just > don't think he's the one that should work around it! Well, I agree and that's why I asked. :-) OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will require quite a bit of (compilation) testing on different architectures. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Sat, 28 Jul 2007, Linus Torvalds wrote: > > And it's the *top*level* code that selects HOTPLUG_CPU. Through > SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND. In other words, the problem seems to be that kernel/power/main.c: suspend_devices_and_enter() does the proper "disable/enable_nonboot_cpus()", but it does so without having enabled CPU hotplug. And you seem to think that it's ACPI that should enable the hotplug, even though the code that actually needs it is _outside_ ACPI. And I think that's wrong, and that this is a bug. So I think the real issue is that we allow that "suspend_devices_and_enter()" code to be compiled without HOTPLUG_CPU in the first place. It's not supposed to work that way. Of course, it may well be that other architectures can happily suspend even with multiple CPU's active, which may be the cause of this mess. But I really think it shouldn't be ACPI that has to select the CPU hotplug, since it's not ACPI that _uses_ it in the first place. Rafael: making a config option for STR (the same way we have a config option for hibernate), and just not allowing it on SMP without HOTPLUG_CPU seems to be the right thing. Len is right in that we do insane things right now (trying to STR with multiple CPU's still active), and I just don't think he's the one that should work around it! 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Sat, 28 Jul 2007, Len Brown wrote: > > That three-liner will crash ACPI+SMP-HOTPLUG_CPU kernels on resume. Explain that to me. There should *be* no resume. ACPI doesn't suspend/resume on its own, I hope. It is all done by the top-level suspend/resume code, not by ACPI. ACPI is a pure helper, and if you've changed that, then I think we need to revert more than a few lines. And it's the *top*level* code that selects HOTPLUG_CPU. Through SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND. This is why it's so *totally* and *utterly* bogus for ACPI to select features that it has nothign what-so-ever to do with. In other words: ACPI isn't in the driving seat. 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thursday 26 July 2007 16:55, Linus Torvalds wrote: > Anyway, I think the ACPI problem really is as trivial as the following > three-liner removal fix. If the user doesn't want suspend, ACPI shouldn't > force it on him. ... > - # for sleep > - select HOTPLUG_CPU if X86 && SMP > - select SUSPEND_SMP if X86 && SMP That three-liner will crash ACPI+SMP-HOTPLUG_CPU kernels on resume. While cpu0 is in a known state when the power goes out, without HOTPLUG_CPU the other cpus (and the memory they touch) are in an indeterminate state. Yes, we could invent a new mechanism to offline the other CPUS before suspend and online them upon resume, but that is what the more general HOTPLUG_CPU code does for us already. Indeed, that is pretty much _all_ that HOTPLUG_CPU code does on X86 -- as we don't have any physical hotplug support today beneath this the logical hotplug support -- you could call it CONFIG_CPU_OFFLINE_ONLINE... > A nicer fix might be to also make some of the ACPI helper routines depend > on whether they are needed or not (which in turn will depend on whether > suspend support has been compiled into the kernel), but quite frankly, > that's secondary at least for me. > > So if we have a few ACPI routines that will never get called (because we > don't even enable the interfaces that would *cause* them to be called), I > don't think that's a huge problem. It's a beauty wart, but nobody really > cares (and it's even something that we could get the compiler to optimize > away for us if we really cared). Re: warts, I agree. My question is why the HOTPLUG_CPU=y code is any different. When I compile HOTPLUG_CPU out of an x86_64 kernel, the kernel shrinks by only 18KB, which on a kernel that has ACPI+SMP doesn't seem like such a big wart. Yes, now that you brought it up, I think it would be just dandy if HOTPLUG_CPU simply got folded into SMP -- for I see little to no benefit to having it as its own config option. But on the assumption that you are not swayed (when was the last time you were?) and you still feel strongly we should be able to exclude ACPI_SLEEP and HOTPLUG_CPU from ACPI+SMP kernels, I'll send you a patch do to that properly. It will largely restores things to how we had them in 2.6.22. It looks like a step backwards to me, but you may see it differently. -Len - 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thursday 26 July 2007 16:55, Linus Torvalds wrote: Anyway, I think the ACPI problem really is as trivial as the following three-liner removal fix. If the user doesn't want suspend, ACPI shouldn't force it on him. ... - # for sleep - select HOTPLUG_CPU if X86 SMP - select SUSPEND_SMP if X86 SMP That three-liner will crash ACPI+SMP-HOTPLUG_CPU kernels on resume. While cpu0 is in a known state when the power goes out, without HOTPLUG_CPU the other cpus (and the memory they touch) are in an indeterminate state. Yes, we could invent a new mechanism to offline the other CPUS before suspend and online them upon resume, but that is what the more general HOTPLUG_CPU code does for us already. Indeed, that is pretty much _all_ that HOTPLUG_CPU code does on X86 -- as we don't have any physical hotplug support today beneath this the logical hotplug support -- you could call it CONFIG_CPU_OFFLINE_ONLINE... A nicer fix might be to also make some of the ACPI helper routines depend on whether they are needed or not (which in turn will depend on whether suspend support has been compiled into the kernel), but quite frankly, that's secondary at least for me. So if we have a few ACPI routines that will never get called (because we don't even enable the interfaces that would *cause* them to be called), I don't think that's a huge problem. It's a beauty wart, but nobody really cares (and it's even something that we could get the compiler to optimize away for us if we really cared). Re: warts, I agree. My question is why the HOTPLUG_CPU=y code is any different. When I compile HOTPLUG_CPU out of an x86_64 kernel, the kernel shrinks by only 18KB, which on a kernel that has ACPI+SMP doesn't seem like such a big wart. Yes, now that you brought it up, I think it would be just dandy if HOTPLUG_CPU simply got folded into SMP -- for I see little to no benefit to having it as its own config option. But on the assumption that you are not swayed (when was the last time you were?) and you still feel strongly we should be able to exclude ACPI_SLEEP and HOTPLUG_CPU from ACPI+SMP kernels, I'll send you a patch do to that properly. It will largely restores things to how we had them in 2.6.22. It looks like a step backwards to me, but you may see it differently. -Len - 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Sat, 28 Jul 2007, Len Brown wrote: That three-liner will crash ACPI+SMP-HOTPLUG_CPU kernels on resume. Explain that to me. There should *be* no resume. ACPI doesn't suspend/resume on its own, I hope. It is all done by the top-level suspend/resume code, not by ACPI. ACPI is a pure helper, and if you've changed that, then I think we need to revert more than a few lines. And it's the *top*level* code that selects HOTPLUG_CPU. Through SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND. This is why it's so *totally* and *utterly* bogus for ACPI to select features that it has nothign what-so-ever to do with. In other words: ACPI isn't in the driving seat. 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Sat, 28 Jul 2007, Linus Torvalds wrote: And it's the *top*level* code that selects HOTPLUG_CPU. Through SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND. In other words, the problem seems to be that kernel/power/main.c: suspend_devices_and_enter() does the proper disable/enable_nonboot_cpus(), but it does so without having enabled CPU hotplug. And you seem to think that it's ACPI that should enable the hotplug, even though the code that actually needs it is _outside_ ACPI. And I think that's wrong, and that this is a bug. So I think the real issue is that we allow that suspend_devices_and_enter() code to be compiled without HOTPLUG_CPU in the first place. It's not supposed to work that way. Of course, it may well be that other architectures can happily suspend even with multiple CPU's active, which may be the cause of this mess. But I really think it shouldn't be ACPI that has to select the CPU hotplug, since it's not ACPI that _uses_ it in the first place. Rafael: making a config option for STR (the same way we have a config option for hibernate), and just not allowing it on SMP without HOTPLUG_CPU seems to be the right thing. Len is right in that we do insane things right now (trying to STR with multiple CPU's still active), and I just don't think he's the one that should work around it! 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Saturday, 28 July 2007 18:55, Linus Torvalds wrote: On Sat, 28 Jul 2007, Linus Torvalds wrote: And it's the *top*level* code that selects HOTPLUG_CPU. Through SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND. In other words, the problem seems to be that kernel/power/main.c: suspend_devices_and_enter() does the proper disable/enable_nonboot_cpus(), but it does so without having enabled CPU hotplug. And you seem to think that it's ACPI that should enable the hotplug, even though the code that actually needs it is _outside_ ACPI. And I think that's wrong, and that this is a bug. So I think the real issue is that we allow that suspend_devices_and_enter() code to be compiled without HOTPLUG_CPU in the first place. It's not supposed to work that way. Of course, it may well be that other architectures can happily suspend even with multiple CPU's active, which may be the cause of this mess. But I really think it shouldn't be ACPI that has to select the CPU hotplug, since it's not ACPI that _uses_ it in the first place. Rafael: making a config option for STR (the same way we have a config option for hibernate), and just not allowing it on SMP without HOTPLUG_CPU seems to be the right thing. Len is right in that we do insane things right now (trying to STR with multiple CPU's still active), and I just don't think he's the one that should work around it! Well, I agree and that's why I asked. :-) OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will require quite a bit of (compilation) testing on different architectures. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Sat, 28 Jul 2007, Rafael J. Wysocki wrote: OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will require quite a bit of (compilation) testing on different architectures. Sure. I'm not too worried, the fallout should be of the trivial kind. Also, mind basing it on the (independent) cleanups that Adrian already sent out. This is all intertwined.. 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thu, 26 Jul 2007, Rafael J. Wysocki wrote: > > My point is we have ACPI dependent on PM, so if you want ACPI, you end > up with all of the STR stuff built in, which is what you don't like (if I > understand that correctly). If we have CONFIG_SUSPEND, you'll be able to > choose ACPI alone. :-) Good point. Anyway, I think the ACPI problem really is as trivial as the following three-liner removal fix. If the user doesn't want suspend, ACPI shouldn't force it on him. A nicer fix might be to also make some of the ACPI helper routines depend on whether they are needed or not (which in turn will depend on whether suspend support has been compiled into the kernel), but quite frankly, that's secondary at least for me. So if we have a few ACPI routines that will never get called (because we don't even enable the interfaces that would *cause* them to be called), I don't think that's a huge problem. It's a beauty wart, but nobody really cares (and it's even something that we could get the compiler to optimize away for us if we really cared). Linus --- Don't force-enable suspend/hibernate support just for ACPI It's a totally independent decision for the user whether he wants suspend and/or hibernation support, and ACPI shouldn't care. Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> --- drivers/acpi/Kconfig |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 251344c..22b401b 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -11,9 +11,6 @@ menuconfig ACPI depends on PCI depends on PM select PNP - # for sleep - select HOTPLUG_CPU if X86 && SMP - select SUSPEND_SMP if X86 && SMP default y ---help--- Advanced Configuration and Power Interface (ACPI) support for - 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thursday, 26 July 2007 21:57, Linus Torvalds wrote: > > On Thu, 26 Jul 2007, Rafael J. Wysocki wrote: > > > > Hmm, perhaps we should introduce a CONFIG_SUSPEND and change > > CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on > > CONFIG_PM? > > > > There's quite some code needed only for suspend compiled in when CONFIG_PM > > is > > set ... > > Sounds like a good idea, although I suspect that CONFIG_PM really *is* > fairly close to CONFIG_SUSPEND. The thing is, all the stuff it enabled is > largely useless without at least STR. My point is we have ACPI dependent on PM, so if you want ACPI, you end up with all of the STR stuff built in, which is what you don't like (if I understand that correctly). If we have CONFIG_SUSPEND, you'll be able to choose ACPI alone. :-) > (Yes, I realize that you can do per-driver suspend events etc, but I > suspect not a lot of people have used it). > > But from a logical standpoint, it does make sense to have a separate > config option for the STR support. Exactly. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thu, 26 Jul 2007, Rafael J. Wysocki wrote: > > Hmm, perhaps we should introduce a CONFIG_SUSPEND and change > CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on > CONFIG_PM? > > There's quite some code needed only for suspend compiled in when CONFIG_PM is > set ... Sounds like a good idea, although I suspect that CONFIG_PM really *is* fairly close to CONFIG_SUSPEND. The thing is, all the stuff it enabled is largely useless without at least STR. (Yes, I realize that you can do per-driver suspend events etc, but I suspect not a lot of people have used it). But from a logical standpoint, it does make sense to have a separate config option for the STR support. 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/
CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thursday, 26 July 2007 19:45, Len Brown wrote: > On Thursday 26 July 2007 02:55, Linus Torvalds wrote: > > > > On Thu, 26 Jul 2007, Len Brown wrote: > > > > > > Feel free to share what you know about the benefits vs. the costs > > > of maintaining CONFIG_ACPI_SLEEP as a build option. > > > > Why don't you just make CONFIG_ACPI_SLEEP dependent on SOFTWARE_SUSPEND > > and STR? > > CONFIG_STR doesn't exist. Hmm, perhaps we should introduce a CONFIG_SUSPEND and change CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on CONFIG_PM? There's quite some code needed only for suspend compiled in when CONFIG_PM is set ... Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thu, 26 Jul 2007, Rafael J. Wysocki wrote: Hmm, perhaps we should introduce a CONFIG_SUSPEND and change CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on CONFIG_PM? There's quite some code needed only for suspend compiled in when CONFIG_PM is set ... Sounds like a good idea, although I suspect that CONFIG_PM really *is* fairly close to CONFIG_SUSPEND. The thing is, all the stuff it enabled is largely useless without at least STR. (Yes, I realize that you can do per-driver suspend events etc, but I suspect not a lot of people have used it). But from a logical standpoint, it does make sense to have a separate config option for the STR support. 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thursday, 26 July 2007 21:57, Linus Torvalds wrote: On Thu, 26 Jul 2007, Rafael J. Wysocki wrote: Hmm, perhaps we should introduce a CONFIG_SUSPEND and change CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on CONFIG_PM? There's quite some code needed only for suspend compiled in when CONFIG_PM is set ... Sounds like a good idea, although I suspect that CONFIG_PM really *is* fairly close to CONFIG_SUSPEND. The thing is, all the stuff it enabled is largely useless without at least STR. My point is we have ACPI dependent on PM, so if you want ACPI, you end up with all of the STR stuff built in, which is what you don't like (if I understand that correctly). If we have CONFIG_SUSPEND, you'll be able to choose ACPI alone. :-) (Yes, I realize that you can do per-driver suspend events etc, but I suspect not a lot of people have used it). But from a logical standpoint, it does make sense to have a separate config option for the STR support. Exactly. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - 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/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thu, 26 Jul 2007, Rafael J. Wysocki wrote: My point is we have ACPI dependent on PM, so if you want ACPI, you end up with all of the STR stuff built in, which is what you don't like (if I understand that correctly). If we have CONFIG_SUSPEND, you'll be able to choose ACPI alone. :-) Good point. Anyway, I think the ACPI problem really is as trivial as the following three-liner removal fix. If the user doesn't want suspend, ACPI shouldn't force it on him. A nicer fix might be to also make some of the ACPI helper routines depend on whether they are needed or not (which in turn will depend on whether suspend support has been compiled into the kernel), but quite frankly, that's secondary at least for me. So if we have a few ACPI routines that will never get called (because we don't even enable the interfaces that would *cause* them to be called), I don't think that's a huge problem. It's a beauty wart, but nobody really cares (and it's even something that we could get the compiler to optimize away for us if we really cared). Linus --- Don't force-enable suspend/hibernate support just for ACPI It's a totally independent decision for the user whether he wants suspend and/or hibernation support, and ACPI shouldn't care. Signed-off-by: Linus Torvalds [EMAIL PROTECTED] --- drivers/acpi/Kconfig |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 251344c..22b401b 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -11,9 +11,6 @@ menuconfig ACPI depends on PCI depends on PM select PNP - # for sleep - select HOTPLUG_CPU if X86 SMP - select SUSPEND_SMP if X86 SMP default y ---help--- Advanced Configuration and Power Interface (ACPI) support for - 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/
CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thursday, 26 July 2007 19:45, Len Brown wrote: On Thursday 26 July 2007 02:55, Linus Torvalds wrote: On Thu, 26 Jul 2007, Len Brown wrote: Feel free to share what you know about the benefits vs. the costs of maintaining CONFIG_ACPI_SLEEP as a build option. Why don't you just make CONFIG_ACPI_SLEEP dependent on SOFTWARE_SUSPEND and STR? CONFIG_STR doesn't exist. Hmm, perhaps we should introduce a CONFIG_SUSPEND and change CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on CONFIG_PM? There's quite some code needed only for suspend compiled in when CONFIG_PM is set ... Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - 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/
