Re: [PATCH 1/5] ACPI / PM: Move references to pm_flags into sleep.c

2011-02-08 Thread Linus Torvalds
On Tue, Feb 8, 2011 at 1:20 PM, Rafael J. Wysocki r...@sisk.pl wrote: If direct references to pm_flags are moved from bus.c to sleep.c, CONFIG_ACPI will not need to depend on CONFIG_PM any more. The patch may _work_, but I really hate it. That function naming is insane:  #ifdef

Re: [PATCH 5/5] PM: Clean up Kconfig dependencies

2011-02-08 Thread Linus Torvalds
Ack on patches 2-5 in this series. It's just patch 1/5 that I think is too ugly/odd to live. Linus -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH 1/5] ACPI / PM: Move references to pm_flags into sleep.c

2011-02-08 Thread Linus Torvalds
On Tue, Feb 8, 2011 at 4:37 PM, Rafael J. Wysocki r...@sisk.pl wrote: but maybe it would be about APM being enabled. Which is what the caller actually seems to care about and talks about for the failure case. Maybe you need separate functions for the is APM enabled case for the naming to make

Re: Wait for console to become available, v3.2

2009-04-21 Thread Linus Torvalds
On Tue, 21 Apr 2009, David VomLehn wrote: What in the world are users going to do when they see a message about output being lost? There is no way to recover the data and no way to prevent it in the future. I don't think this is a good approach. Sure there is. The console messages are

Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

2008-08-27 Thread Linus Torvalds
On Wed, 27 Aug 2008, Paul Mackerras wrote: I think your memory is failing you. In 2.4 and earlier, the kernel stack was 8kB minus the size of the task_struct, which sat at the start of the 8kB. Yup, you're right. Linus -- To unsubscribe from this list: send the

Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

2008-08-26 Thread Linus Torvalds
On Tue, 26 Aug 2008, Adrian Bunk wrote: If you think we have too many stacksize problems I'd suggest to consider removing the choice of 4k stacks on i386, sh and m68knommu instead of using -fno-inline-functions-called-once: Don't be silly. That makes the problem _worse_. We're much

Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

2008-08-26 Thread Linus Torvalds
On Tue, 26 Aug 2008, Parag Warudkar wrote: This is something I never understood - embedded devices are not going to run more than a few processes and 4K*(Few Processes) IMHO is not worth a saving now a days even in embedded world given falling memory prices. Or do I misunderstand? Well,

Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

2008-08-26 Thread Linus Torvalds
On Wed, 27 Aug 2008, Adrian Bunk wrote: We're much better off with a 1% code-size reduction than forcing big stacks on people. The 4kB stack option is also a good way of saying if it works with this, then 8kB is certainly safe. You implicitely assume both would solve the same

Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

2008-08-26 Thread Linus Torvalds
On Tue, 26 Aug 2008, Parag Warudkar wrote: And although you said in your later reply that Linux x86 with 4K stacks should be more than usable - my experiences running a untainted desktop/file server with 4K stack have been always disastrous XFS or not. It _might_ work for some well defined

Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

2008-08-26 Thread Linus Torvalds
On Tue, 26 Aug 2008, Parag Warudkar wrote: What about deep call chains? The problem with the uptake of 4K stacks seems to be that is not reliably provable that it will work under all circumstances. Umm. Neither is 8k stacks. Nobody proved anything. But yes, some subsystems have insanely