On Mon, May 31, 2010 at 11:47 PM, Florian Mickler <[email protected]> wrote:
> On Mon, 31 May 2010 22:12:19 +0200
> Florian Mickler <[email protected]> wrote:
>> If I have a simple shell script then I don't wanna jump through
>> hoops just to please your fragile kernel.
>
> Also why should that code on one device kill my uptime and on the
> other machine (my wall-plugged desktop) work just well? That doesn't
> sound right.
Sounds perfectly right to me; one code runs perfectly fine on one
machine, and on the other doesn't even compile. Well, sure, it wasn't
written with that use-case in mind.
> Clearly opportunistic suspend is a workaround for battery-driven devices
> and no general solution. But it is not specific to android. At least
> not inherently. It could be useful for any embedded or mobile device
> where you can clearly distinguish important functions from convenience
> functions.
Yes, it could, but why go for the hacky solution when we know how to
achieve the ideal one?
> I really can't understand the whole _fundamental_ opposition to this
> design choice.
Nobody is using it, except Android. Nobody will use it, except Android.
I have seen recent proposals that don't require changing the whole
user-space. That might actually be used by other players.
--
Felipe Contreras
On Saturday 05 June 2010, Felipe Contreras wrote:
> On Mon, May 31, 2010 at 11:47 PM, Florian Mickler <[email protected]> wrote:
> > On Mon, 31 May 2010 22:12:19 +0200
> > Florian Mickler <[email protected]> wrote:
> >> If I have a simple shell script then I don't wanna jump through
> >> hoops just to please your fragile kernel.
> >
> > Also why should that code on one device kill my uptime and on the
> > other machine (my wall-plugged desktop) work just well? That doesn't
> > sound right.
>
> Sounds perfectly right to me; one code runs perfectly fine on one
> machine, and on the other doesn't even compile. Well, sure, it wasn't
> written with that use-case in mind.
>
> > Clearly opportunistic suspend is a workaround for battery-driven devices
> > and no general solution. But it is not specific to android. At least
> > not inherently. It could be useful for any embedded or mobile device
> > where you can clearly distinguish important functions from convenience
> > functions.
>
> Yes, it could, but why go for the hacky solution when we know how to
> achieve the ideal one?
>
> > I really can't understand the whole _fundamental_ opposition to this
> > design choice.
>
> Nobody is using it, except Android. Nobody will use it, except Android.
That's like saying "Android is not a legitimate user of the kernel". Is that
you wanted to say?
> I have seen recent proposals that don't require changing the whole
> user-space. That might actually be used by other players.
Sure, an approach benefitting more platforms than just Android would be better,
but saying that the kernel shouldn't address the Android's specific needs as a
rule if no one else has those needs too is quite too far reaching to me.
Rafael
On Sat, 2010-06-05 at 21:04 +0200, Rafael J. Wysocki wrote:
>
> > I have seen recent proposals that don't require changing the whole
> > user-space. That might actually be used by other players.
>
> Sure, an approach benefitting more platforms than just Android would be better,
> but saying that the kernel shouldn't address the Android's specific needs as a
> rule if no one else has those needs too is quite too far reaching to me.
Well, if the android people keep rejecting all sensible approaches to
power savings except their suspend blocker mess, then I don't see why we
should support their ill designed mess.
We should strive to provide an interface that can be used by all
interested parties to conserve power; if Android really is the only
possible user of the interface then I don't see any reason at all to
merge it, they might as well keep it in their private tree.
On Saturday 05 June 2010, Peter Zijlstra wrote:
> On Sat, 2010-06-05 at 21:04 +0200, Rafael J. Wysocki wrote:
> >
> > > I have seen recent proposals that don't require changing the whole
> > > user-space. That might actually be used by other players.
> >
> > Sure, an approach benefitting more platforms than just Android would be better,
> > but saying that the kernel shouldn't address the Android's specific needs as a
> > rule if no one else has those needs too is quite too far reaching to me.
>
> Well, if the android people keep rejecting all sensible approaches to
> power savings except their suspend blocker mess, then I don't see why we
> should support their ill designed mess.
Well, I certainly would like the Android people to be more appreciative of our
ideas if they expect reciprocity.
> We should strive to provide an interface that can be used by all
> interested parties to conserve power; if Android really is the only
> possible user of the interface then I don't see any reason at all to
> merge it, they might as well keep it in their private tree.
There is a number of kernel users that depend on Android user space
(phone vendors using Android on their hardware, but providing their own
drivers), so I don't think we really can identify Android with Google in that
respect.
Rafael
On Sat, 2010-06-05 at 21:39 +0200, Rafael J. Wysocki wrote:
>
> There is a number of kernel users that depend on Android user space
> (phone vendors using Android on their hardware, but providing their own
> drivers), so I don't think we really can identify Android with Google in that
> respect.
I don't see why we can't merge the platform code and drivers without
suspend blockers. Google can patch them back in on their side if they
want to.
On Sat, Jun 5, 2010 at 10:04 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Saturday 05 June 2010, Felipe Contreras wrote:
>> On Mon, May 31, 2010 at 11:47 PM, Florian Mickler <[email protected]> wrote:
>> > On Mon, 31 May 2010 22:12:19 +0200
>> > Florian Mickler <[email protected]> wrote:
>> >> If I have a simple shell script then I don't wanna jump through
>> >> hoops just to please your fragile kernel.
>> >
>> > Also why should that code on one device kill my uptime and on the
>> > other machine (my wall-plugged desktop) work just well? That doesn't
>> > sound right.
>>
>> Sounds perfectly right to me; one code runs perfectly fine on one
>> machine, and on the other doesn't even compile. Well, sure, it wasn't
>> written with that use-case in mind.
>>
>> > Clearly opportunistic suspend is a workaround for battery-driven devices
>> > and no general solution. But it is not specific to android. At least
>> > not inherently. It could be useful for any embedded or mobile device
>> > where you can clearly distinguish important functions from convenience
>> > functions.
>>
>> Yes, it could, but why go for the hacky solution when we know how to
>> achieve the ideal one?
>>
>> > I really can't understand the whole _fundamental_ opposition to this
>> > design choice.
>>
>> Nobody is using it, except Android. Nobody will use it, except Android.
>
> That's like saying "Android is not a legitimate user of the kernel". Is that
> you wanted to say?
Read the context: opportunistic suspend, which is considered a
workaround, which requires new user-space API for suspend blockers,
might be remotely considered for inclusion *if* it indeed solves a
problem for battery-driven devices, which other parties also
experience and could benefit from this solution.
The answer: no, it doesn't: only Android user-space will benefit from it.
>> I have seen recent proposals that don't require changing the whole
>> user-space. That might actually be used by other players.
>
> Sure, an approach benefitting more platforms than just Android would be better,
> but saying that the kernel shouldn't address the Android's specific needs as a
> rule if no one else has those needs too is quite too far reaching to me.
There are no Android specific needs, why should certain user-space
ecosystem need certain API that somehow *nobody* else does? I think in
this huge thread it has become obvious that people are reluctant to
this idea... whatever problem Android user-space presents (I don't
think there's any), it can be solved for "he rest of the world" too,
and such generic solution is worth exploring.
--
Felipe Contreras