On Thu, May 27, 2010 at 11:55:46PM +0100, Alan Cox wrote:
This started because the Android people came to a meeting that was put
together of various folks to try and sort of the big blockage in getting
Android and Linux kernels back towards merging.
I am interested right now in finding a
On Thu, May 27, 2010 at 3:55 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
This started because the Android people came to a meeting that was put
together of various folks to try and sort of the big blockage in getting
Android and Linux kernels back towards merging.
I am interested right now
On Thu, 2010-05-27 at 15:19 -0400, Alan Stern wrote:
On Thu, 27 May 2010, Peter Zijlstra wrote:
I still don't see how blocking applications will cause missed wakeups in
anything but a buggy application at worst, and even those will
eventually get the event when they unblock.
What
On Wed, May 26, 2010 at 12:02 PM, Florian Mickler flor...@mickler.org wrote:
So why again was this such a great scheme? Go fix your userspace to not
not run when not needed.
Hi Peter!
This was already mentioned in one of these threads.
The summary is: The device this kernel is running on
2010/5/26 Arve Hjønnevåg a...@android.com:
Fixing the actually issue means fixing all user-space code, and
replacing most x86 hardware. I don't think keeping this feature out of
the kernel will significantly accelerate this.
But if this feature gets merged, I bet you'll find another 100
On Wed, May 26, 2010 at 1:37 PM, Florian Mickler flor...@mickler.org wrote:
This is not protection. This is functioning properly in a real world
scenario. Why would the user change the kernel, if the device would be
buggy after that? (Except maybe he is a geek)
Hmm... Why would the user
On Wed, 26 May 2010 14:01:49 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
On Wed, May 26, 2010 at 1:37 PM, Florian Mickler flor...@mickler.org wrote:
This is not protection. This is functioning properly in a real world
scenario. Why would the user change the kernel, if the device would be
hi,
On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
And if you have two kernels, one with which your device is dead after 1
hour and one with which your device is dead after 10 hours. Which would
you prefer? I mean really... this is ridiculous.
What I find ridiculous is
On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi felipe.ba...@nokia.com wrote:
hi,
On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
And if you have two kernels, one with which your device is dead after 1
hour and one with which your device is dead after 10 hours. Which
Hi,
On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote:
But then someone at the user side has to know what he is doing.
I fear, if you target mass market without central distribution
channels, you can not assume that much.
and that's enough to push hacks into the kernel ? I
On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi felipe.ba...@nokia.com wrote:
hi,
On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
And if you have two kernels, one with which your device is dead after 1
On Wed, 26 May 2010 15:35:32 +0300
Felipe Balbi felipe.ba...@nokia.com wrote:
Hi,
On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote:
But then someone at the user side has to know what he is doing.
I fear, if you target mass market without central distribution
channels,
On Wed, May 26, 2010 at 2:24 PM, Florian Mickler flor...@mickler.org wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)
And if you have two kernels, one with which your device is dead after 1
On Wed, 26 May 2010 14:41:29 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi felipe.ba...@nokia.com wrote:
hi,
On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler
On Wed, 2010-05-26 at 14:54 +0200, Florian Mickler wrote:
It really comes down to a policy decision by the distribution maker.
And I don't think kernel upstream should be the one to force one way or
the other.
That's exactly what we always do. If we were not to do so, the kernel
would be a
On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote:
The kernel can not win if it does not try to integrate any use of it.
If we'd integrate every patch that came to lkml, you'd run away
screaming.
We most certainly do not want to integrate _any_ use.
--
To unsubscribe from this list: send
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)
And if you have two kernels, one with which your device is dead after 1
hour and one with which your device is dead after 10 hours. Which would
Nonetheless, I really think the kernel needs to allow for the android
way of power saving. It misses out on a big feature and a big user-base
if not.
That seems to me to be conflating models of behaviour and implementations.
This is a _big_ plus for attracting 3rd party programs. (And of
On Wed, 26 May 2010 14:55:31 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
On Wed, May 26, 2010 at 2:24 PM, Florian Mickler flor...@mickler.org wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
On Wed, 26 May 2010 15:07:27 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote:
The kernel can not win if it does not try to integrate any use of it.
If we'd integrate every patch that came to lkml, you'd run away
screaming.
We
On Wed, 26 May 2010 14:19:42 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
This is a _big_ plus for attracting 3rd party programs. (And of course
the thing you don't like).
You would do better to concentrate on technical issues that the
assignment of malicious intent to other parties.
Alan,
On Wed, 26 May 2010, Alan Cox wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)
And if you have two kernels, one with which your device is dead after 1
hour and one with which
On Wed, 26 May 2010, Florian Mickler wrote:
I don't think that the in-kernel suspend block is a bad idea.
You could probably use the suspend-blockers unconditionally in the
suspend framework to indicate if a suspend is possible or not.
That's not how it works. Drivers aren't supposed to
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
I'm not saying that your argument is not valid. But why don't you look
at suspend blockers as a contract between userspace and kernelspace? An
Opt-In to the current guarantees the kernel provides in the non-suspend
case.
That's
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
If you don't want to suspend while
looking at the bouncing-cow, you have to take a suspend blocker and
make yourself a user-visible power-eater, or don't do
echo opportunistic /sys/power/policy
How about we don't merge that junk
Alan Cox a...@lxorguk.ukuu.org.uk writes:
[1] Note I disagree with Kevin here on static/dynamic power management.
There are IMHO two types of PM but they are 'user invoked' and
'automatic'. Static simply means it's not been made fast enough yet but
its just a policy divide dependant on the
Hi,
On Wed, May 26, 2010 at 03:46:55PM +0200, Thomas Gleixner wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)
And if you have two kernels, one with which your device is dead
I'm not saying that your argument is not valid. But why don't you look
at suspend blockers as a contract between userspace and kernelspace? An
Opt-In to the current guarantees the kernel provides in the non-suspend
case.
It is a contract - but not the right one. You are removing autonomy from
On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
I'm not saying that your argument is not valid. But why don't you look
at suspend blockers as a contract between userspace and kernelspace? An
Opt-In to
On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
I'm not saying that your argument is not valid. But why don't you look
at suspend blockers
On Wed, 26 May 2010 17:45:00 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
I'm not
On Wed, 26 May 2010 17:47:35 +0200
Florian Mickler flor...@mickler.org wrote:
On Wed, 26 May 2010 17:45:00 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra pet...@infradead.org
Florian,
On Wed, 26 May 2010, Florian Mickler wrote:
On the other hand, applications can say, they don't need that much
power and userspace guaranties and not take a suspend blocker.
This is an option which they currently don't have.
Wrong. A well coded power aware application is very well
The power efficiency of a mobile device is depending on a sane overall
software stack and not on the ability to mitigate crappy software in
some obscure way which is prone to malfunction and disappoint users.
Even if you believe the kernel should be containing junk the model that
works and is
On Wed, 26 May 2010 19:02:04 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
The power efficiency of a mobile device is depending on a sane overall
software stack and not on the ability to mitigate crappy software in
some obscure way which is prone to malfunction and disappoint users.
On Wed, May 26, 2010 at 9:56 PM, Florian Mickler flor...@mickler.org wrote:
Your approach definitely sounds better than the current solution.
What about mapping suspend blocker functionality later on, when this
interface exists, on to this new approach and deprecating it?
What about coming
suspend blockers are completely backwards as they basically disable
the kernels ability to do resource management.
I don't think this is a defect in the approach but the point of it.
I think it's both. It's the point of it, and that itself is a defect. Its
designed wrongly.
drivers code
On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)
And if you have two kernels, one with which your device is dead after 1
On Wed, 26 May 2010 15:30:58 -0700
Arve Hjønnevåg a...@android.com wrote:
On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows
2010/5/26 Alan Cox a...@lxorguk.ukuu.org.uk:
On Wed, 26 May 2010 15:30:58 -0700
Arve Hjønnevåg a...@android.com wrote:
On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from
On Wed, 26 May 2010 22:03:37 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
On Wed, May 26, 2010 at 9:56 PM, Florian Mickler flor...@mickler.org wrote:
Your approach definitely sounds better than the current solution.
What about mapping suspend blocker functionality later on, when this
On Wed, 26 May 2010 23:09:43 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
We now have suggestions how to do the job properly so the right thing is
probably to go and explore those suggestions not merge crap.
Merging crap won't help anyway. The rest of the kernel community can
still simply
401 - 442 of 442 matches
Mail list logo
