new kernel ... / meaning of stable-tracking

Werner Almesberger werner at openmoko.org
Mon Sep 29 09:45:43 CEST 2008


Mike (mwester) wrote:
> still user-space, and I'm quite certain there are still failure modes
> where it will die along with all userspace, when a simple bit of kernel
> code can still quite capably run.

Well, the question is what cases are actually relevant. There are
a number of ways how you can cripple neodog, sure. But the stated
purpose of that forced power off was to have a convenient way to
reset the system when user space is badly broken.

For this goal, it doesn't have to be perfect. And even if it was
perfectly resilient to anything user space could possibly throw at
it, that wouldn't matter, since the kernel itself can fail easily
enough.

In the truly hopeless cases, you can still power cycle.

I'm actually very surprised by your hostile reaction to this change.
It replaces the functionality currently provided by incorrect code
in the kernel and eliminates the need to re-implement that code in
the kernel, which would also add a number of new interactions between
the PMU driver and the platform code, making both more complex. So
it saves time, makes the code cleaner and simpler, and makes it a
lot easier to customize this function. (E.g., what if you'd prefer
to reboot instead of powering down ? This is a trivial change with
neodog, but it would be a small nightmare for people who aren't
kernel developers with the kernel-centric approach.)

Anyway, this emergency power-down is Mickey's pet feature. Mickey,
since this seems to be something you use often enough, could you
please give neodog a try and see if it works well enough for you ?

I've attached a quick and dirty kernel patch that gets rid of the
kernel-based emergency power down. (Without cleaning it up
completely. Hence the "dirty" :-)

- Werner
-------------- next part --------------
Index: korig/drivers/i2c/chips/pcf50633.c
===================================================================
--- korig.orig/drivers/i2c/chips/pcf50633.c	2008-09-29 02:50:25.000000000 -0300
+++ korig/drivers/i2c/chips/pcf50633.c	2008-09-29 02:50:51.000000000 -0300
@@ -948,38 +948,6 @@
 			DEBUGPC("SECOND ");
 			rtc_update_irq(pcf->rtc, 1, RTC_PF | RTC_IRQF);
 		}
-
-		if (pcf->onkey_seconds >= 0 &&
-		    pcf->flags & PCF50633_F_PWR_PRESSED) {
-			DEBUGP("ONKEY_SECONDS(%u, OOCSTAT=0x%02x) ",
-				pcf->onkey_seconds,
-				reg_read(pcf, PCF50633_REG_OOCSTAT));
-			pcf->onkey_seconds++;
-			if (pcf->onkey_seconds >=
-			    pcf->pdata->onkey_seconds_sig_init) {
-				/* Ask init to do 'ctrlaltdel' */
-				/*
-				 * currently Linux reacts badly to issuing a
-				 * signal to PID #1 before init is started.
-				 * What happens is that the next kernel thread
-				 * to start, which is the JFFS2 Garbage
-				 * collector in our case, gets the signal
-				 * instead and proceeds to fail to fork --
-				 * which is very bad.  Therefore we confirm
-				 * PID #1 exists before issuing the signal
-				 */
-				if (find_task_by_pid(1)) {
-					DEBUGPC("SIGINT(init) ");
-					kill_proc(1, SIGINT, 1);
-				}
-				/* FIXME: what if userspace doesn't shut down? */
-			}
-			if (pcf->onkey_seconds >=
-				pcf->pdata->onkey_seconds_shutdown) {
-				DEBUGPC("Power Off ");
-				pcf50633_go_standby();
-			}
-		}
 	}
 
 	if (pcfirq[1] & PCF50633_INT2_ONKEYF) {


More information about the openmoko-kernel mailing list