On Mon, Jun 08, 2009 at 04:24:50PM +0200, Ingo Molnar wrote: > * Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > > eSATA is pretty common now. > > [ And 99% of the CPUs have an IDT still 99.9% of the users dont know > what it is :) ] Users know that there's a socket on the front of their computer that they can plug a hard drive into, and if that doesn't work then they're going to be upset. > > 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. So, like I said, the kernel can't automatically suspend AHCI unless it's received some information from elsewhere that tells it it's ok to. The kernel can't know if there's an eSATA port or not. > > 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. Yes. And powersaving is a tradeoff between functionality and power consumption. The kernel doesn't know what level of functionality a given user requires. It *can't* know that itself. > > 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? To the best of my knowledge, yes. > > 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. No, we can't just close it - then we won't get notification that a key's been hit in order to unlock the screensaver. Yes, we can greatly expand the userland-visible interface to every piece of hardware in order to make this work, but that's a huge amount of effort to avoid a model where userspace sets some tunables appropriately. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
