From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: Run-time PM idea (was: Re: [linux-pm] [RFC][PATCH 0/2] PM: Rearrange core suspend code) Date: Mon, 8 Jun 2009 16:24:50 +0200 Message-ID: <20090608142450.GE14234@elte.hu> References: <200906072347.00580.rjw@sisk.pl> <20090608065419.GA13568@elte.hu> <200906081330.50045.rjw@sisk.pl> <20090608130509.GA3272@elte.hu> <20090608131159.GA15100@srcf.ucam.org> <20090608132235.GC13214@elte.hu> <20090608133215.GA15482@srcf.ucam.org> <20090608134647.GA14234@elte.hu> <20090608135431.GA16052@srcf.ucam.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mx2.mail.elte.hu ([157.181.151.9]:48702 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754530AbZFHOZC (ORCPT ); Mon, 8 Jun 2009 10:25:02 -0400 Content-Disposition: inline In-Reply-To: <20090608135431.GA16052@srcf.ucam.org> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Matthew Garrett Cc: "Rafael J. Wysocki" , Alan Stern , pm list , ACPI Devel Maling List , LKML , Magnus Damm * Matthew Garrett wrote: > On Mon, Jun 08, 2009 at 03:46:47PM +0200, Ingo Molnar wrote: > > > > * Matthew Garrett wrote: > > > > How does the kernel know whether the user cares about SATA > > > hotplug or not? > > > > The typical user probably doesnt know what 'SATA' means, and > > probably has very vague concepts about 'hotplug' as well. > > eSATA is pretty common now. [ And 99% of the CPUs have an IDT still 99.9% of the users dont know what it is :) ] > > The kernel default should be: 'yes, if the kernel feature is > > enabled and if the hardware can support it' (it's not on a > > blacklist of some sort, etc., etc.). > > The problem with this kind of default is that you get people who > are confused that their hardware doesn't work. If the hardware 'doesnt work' that is a kernel bug. Hardware that _cannot be suspended_ safely (physically) should not be auto-suspended, of course. > If the kernel doesn't have enough information to make a decision > it should err on the side of functionality - we're talking about > fairly low-level power savings, but potentially several years of > aggregate confusion on the part of users. the difference between a 10W and a 1W footprint is a long series of 'low-level power savings'. If users are getting confused and if hardware gets broken then tha's a plain bug and the wrong path is being walked. > > What sources of information exactly? Again, the user wont enter > > anything, in 95% of the cases - in the remaining 3% of cases > > what is entered is wrong and only in another 2% of cases is it > > correct ;-) > > Users are generally ok at realising correlation between a setting > change and something no longer working, so as long as you provide > that they'll be happy. I agree that this sucks. What we actually > want is some means of reliably identifying whether a port is > hotplug or not, but eSATA makes this very difficult. Is it impossible? > > Sure, there might be tradeoffs when a piece of hardware cannot > > be turned off sanely: obviously the monitor might not know it > > (currently) whether someone is watching it, and > > wake-on-packet-for-me is not commonly implemented in wireless > > and wired networking cards so turning off an active networking > > card might not be possible without the user asking allowing that > > imperfect mode of power saving. > > These cases can all be handled with sufficiently intelligent > userland, so I'm not worried about them. > > > ( Providing a way to _override_ those defaults is of course natural, > > via /sysfs, should the user express an interest in tweaking it, or > > should the kernel get it so wrong that a distro wants to work it > > around. But your argument seems to be "push configuration and > > handling into user-space" which is really backwards. ) > > My argument is "Hardware should work, and if the kernel default is > for it to be broken then the default is wrong". We went through > this for USB autosuspend. Userspace simply has more available > information than the kernel, and it's not just a matter of static > configuration (though that may be part of it). For instance, > Oliver's example of screensavers and USB keyboards. If nothing's > paying attention to volume keys (or if the keyboard doesn't have > any) then you can enable remote wakeup and suspend the keyboard. > If something /is/ paying attention to volume keys, you can't do > that. That's the kind of case I'm discussing. See my reply to Oliver. This is really advocating a broken model of device usage. That volume key usage dependency is being hidden from the kernel, and then you want to kludge it around by pushing suspend functionality to user-space? That way lies madness. The proper way is to close the device if it's not used by anything. Then the kernel can auto-suspend it just like it could auto-suspend network interfaces that are not in use, or like it could auto-suspend a dislay port that has no monitor or other output device attached. Ingo