Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module

2010-01-17 Thread Russell King - ARM Linux
On Sun, Jan 17, 2010 at 02:07:39PM +0100, Pavel Machek wrote:
 AFAICT following message would be nice.
 
 1) battery is critical, userspace please do something
 
 On zaurus and similar, you could add
 
 2) oh and btw we had power failure so we suspended (or maybe -- so
 hardware suspended itself -- rmk's examples and old apm systems); we
 are now back and running
 
 notification... but... ideally those power failures should never
 happen anyway, so... having this notification is in no way neccessary.

There's another consideration here: the more complex the emergency
procedure, the higher the chance of _something_ causing it to fail,
and if it does fail, the result is data loss.

In a properly running system, this isn't something that's going to
get a lot of testing, so there's a higher chance that there will be
bugs, so the simpler the solution, the better.

It's a bit like the kernel shutdown paths - because they don't get a
lot of use, they don't get tested enough, and having discussed it with
Arjan van de Ven, it's a known weakness.  So we know that they're not
that well tested - and the result is eg, 33-rc3 on shutdown results
in an oops for me on x86.

You really don't want to oops or deadlock on battery critically low.

___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel


Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module

2010-01-16 Thread Pavel Machek
Hi!

   I wasn't aware of this.
   
   That may be a good reason for adding kernel-based suspend notification,
   although I'd prefer ARM to notify the user space about the critical 
   battery
   status allowing it to decide what to do.
  
  Hard to do, without breaking compatibility that goes down to 2.4.X.
 
 Sending a battery-critical notification to the user space is not equivalent to
 removing the existing kernel-based mechanism.  They can exist both at the
 same time if the notification is sent earlier than the kernel suspends
 everything. 

Yes, and obviously sending notification early is ok with me.

  It really makes sense on zaurus. Those machines are simple, no
  smartbattery and no embedded controller subsystems. Battery will not
  protect itself, and its kernel job. (Should work on init=/bin/bash).
  
  As power-off consumption is same as suspend power consumption (I
  beleive zaurus simply does not have true power off), suspend on
  critical makes some sense. (Note that it is set lower than on pcs, and
  that we declare battery critical sooner than that.)
 
 The problem with that is it catches at least some applications unprepared and
 notifying them that we're suspending right now doesn't really help, because
 they won't have any time to react anyway.

Agreed, but so what? On PC, machine would power off at that
point. That would surprise the apps, too.

Basically new enough userland should not make battery run low enough
for either emergency power off or emergency suspend.

IOW nothing to see here, problem does not exist.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel


Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module

2010-01-16 Thread Pavel Machek
On Sat 2010-01-16 18:00:58, Stanislav Brabec wrote:
 Eric Miao wrote:
 
  And the other way we may need to look into what API the current userland
  apps on zaurus is depending on this 2.4 compatibility and make changes
  slowly to those apps.
 
 I guess that 2.4 compatibility is not an issue. Most modern Zaurus
 distributions are even unable to run Sharp ROM compatible binaries.
 
 Distributions either stay on 2.4 kernel or use modern systems based on
 modern kernel 2.6 API.
 
 Distributions that decided to migrate to kernel 2.6 are far from
 finished state. Any change that allows to use modern applications using
 standard kernel API is welcome.

There is no API involved. It is just ... if you leave zaurus in
 init=/bin/bash mode, it must not kill the battery. Smart and
 currently implemented way to do that is to suspend.

That's counterexample to rjw, but it does not matter -- reasonable
userland should never ever hit that, in a same way PCs should not hit
emergency power cut...
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel


Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module

2010-01-16 Thread Rafael J. Wysocki
On Saturday 16 January 2010, Pavel Machek wrote:
 On Sat 2010-01-16 18:00:58, Stanislav Brabec wrote:
  Eric Miao wrote:
  
   And the other way we may need to look into what API the current userland
   apps on zaurus is depending on this 2.4 compatibility and make changes
   slowly to those apps.
  
  I guess that 2.4 compatibility is not an issue. Most modern Zaurus
  distributions are even unable to run Sharp ROM compatible binaries.
  
  Distributions either stay on 2.4 kernel or use modern systems based on
  modern kernel 2.6 API.
  
  Distributions that decided to migrate to kernel 2.6 are far from
  finished state. Any change that allows to use modern applications using
  standard kernel API is welcome.
 
 There is no API involved. It is just ... if you leave zaurus in
  init=/bin/bash mode, it must not kill the battery. Smart and
  currently implemented way to do that is to suspend.

IMHO it should just plain shutdown in that case.  Suspending doesn't really
solve the problem, because the battery is going to drain still.  Unless you
mean suspend=hibernate, but I guess you don't.

 That's counterexample to rjw, but it does not matter -- reasonable
 userland should never ever hit that, in a same way PCs should not hit
 emergency power cut...

I don't really understand what you mean.  The user space doesn't know the
battery state if the kernel doesn't tell it, AFAICS, so how exactly can it
predict the critical battery condition without the kernel notifying it?

Rafael

___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel


Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module

2010-01-16 Thread Rafael J. Wysocki
On Saturday 16 January 2010, Pavel Machek wrote:
 Hi!
 
   Agreed, but so what? On PC, machine would power off at that
   point. That would surprise the apps, too.
   
   Basically new enough userland should not make battery run low enough
   for either emergency power off or emergency suspend.
  
  I wonder how it is supposed to achieve that without knowing the current 
  battery
  status.  Do you mean it should poll the battery driver?
 
 That's besides point, is it?

Well, mentioned that first. :-)

 Usual kernel-user interfaces should apply here.

And we're talking about the design of these, aren't we?  The notification about
the critical battery status sent to the user space is a part of the kernel-user
space interface too, after all.

Rafael

___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel