[PATCH 0/8] Suspend block api (version 6)
in [Kernel]
|
Prev: [PATCH 8/8] power_supply: Block suspend while power supply change notifications are pending
Next: [PATCH 7/8] Input: Block suspend while event queue is not empty.
From: Brian Swetland on 13 May 2010 14:20 On Thu, May 13, 2010 at 10:33 AM, Daniel Walker <dwalker(a)fifo99.com> wrote: > On Thu, 2010-05-13 at 13:17 +0100, Matthew Garrett wrote: >> On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote: >> > >> > Figuring out a different way to do this should not limit Android at all, >> > since Google can do what other Linux distributions do and continue to >> > patch opportunistic suspend/suspend-block calls into their kernels as >> > needed to ship devices, while contributing towards a different solution to >> > the problem. >> >> I basically agree, except that despite having a year to do so none of us >> have come up with a different way that would actually work. Google have >> done this work. Who's going to prove that there is actually a different >> way to do this? > > We all feel the pain of inelegance right? I think it's clear that this > system will not last (but there's no other immediate option) .. That > doesn't mean we should reject it, but we need to be clear that this > system will get replaced. So we should format the patches appropriately. > To me the userspace aspect is a permanent change .. If we could drop > that (or put it into debugfs) then it would make this a lot easy to > accept as a stepping stone. I'm in agreement on the first half of this -- from the Google/Android point of view, if we can someday accomplish everything we need with some different facility, we'll happily shift over to that. That seems like a normal operating mode for mainline -- new solutions arise, drivers are migrated to those new solutions, old solutions fall to the wayside. We fully expect that the world will change over time and one of our largest goals with trying to get work upstream is to reduce the pain of those changes for everyone, while trying to get to "you can build a kernel out of the box from mainline that Just Works with an android userspace". I'm not sure this necessitates using only debugfs for the userspace interface. A userspace interface is necessary to accomplish what we're trying to do here, otherwise we have only half a solution, and our hope is that it'd be a stable interface (as userspace interfaces are supposed to be) for as long as its needed. I could totally imagine the userspace interface eventually becoming a no-op or punching through to some other facility, depending on how this problem is solved long-term in the ideal post-suspend-block future. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Walker on 13 May 2010 14:30 On Thu, 2010-05-13 at 11:17 -0700, Brian Swetland wrote: > > I'm not sure this necessitates using only debugfs for the userspace > interface. A userspace interface is necessary to accomplish what > we're trying to do here, otherwise we have only half a solution, and > our hope is that it'd be a stable interface (as userspace interfaces > are supposed to be) for as long as its needed. I could totally > imagine the userspace interface eventually becoming a no-op or > punching through to some other facility, depending on how this problem > is solved long-term in the ideal post-suspend-block future. The problem is that once this userspace interface is exposed, it's nearly permanent and has to be support for a long long time .. It might seen trivial to just remove something your not using, but we never know who is using what once the kernel is released. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 13 May 2010 14:40 On Thu, May 13, 2010 at 11:25:57AM -0700, Daniel Walker wrote: > The problem is that once this userspace interface is exposed, it's > nearly permanent and has to be support for a long long time .. It might > seen trivial to just remove something your not using, but we never know > who is using what once the kernel is released. Deprecating sysfs interfaces can be done within 6 months or so, especially if there's only one real consumer. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Walker on 13 May 2010 15:10 On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote: > On Thu, May 13, 2010 at 11:25:57AM -0700, Daniel Walker wrote: > > > The problem is that once this userspace interface is exposed, it's > > nearly permanent and has to be support for a long long time .. It might > > seen trivial to just remove something your not using, but we never know > > who is using what once the kernel is released. > > Deprecating sysfs interfaces can be done within 6 months or so, > especially if there's only one real consumer. I'll assume your right (can you give an example of this?), but why should we even add it if we know it's already going to get replaced. It's like it's pre-deprecated .. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 13 May 2010 15:20
On Thu, May 13, 2010 at 11:59:37AM -0700, Daniel Walker wrote: > On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote: > > Deprecating sysfs interfaces can be done within 6 months or so, > > especially if there's only one real consumer. > > I'll assume your right (can you give an example of this?), but why > should we even add it if we know it's already going to get replaced. > It's like it's pre-deprecated .. See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |