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 Woodhouse wrote: We can provide un-hooked-up /dev/console though. Rather than just failing to open it, why can't we make __tty_open() give you a dummy tty driver which is basically equivalent to /dev/null? And then 'replace' it with the real console driver

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, Jamie Lokier wrote: A function which is only called from one place should, if everything made sense, _never_ use more stack through being inlined. But that's simply not true. See the whole discussion. The problem is that if you inline that function, the stack usage of

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: I had in mind that we anyway have to support it for tiny kernels. I actually don't think that is true. If we really were to decide to be stricter about it, and it makes a big size difference, we can probably also add a tool to warn about functions

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 Wed, 27 Aug 2008, Adrian Bunk wrote: When did we get callpaths like like nfs+xfs+md+scsi reliably working with 4kB stacks on x86-32? XFS may never have been usable, but the rest, sure. And you seem to be making this whole argument an excuse to SUCK, adn an excuse to let gcc crap even

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