new kernel ... / meaning of stable-tracking

[Balaji Rao]

On Tue, 30 Sep 2008 20:34:07 -0300
Werner Almesberger <werner at openmoko.org> wrote:

> andrzej zaborowski wrote:
> > First was when I was booting off the sd for the first time and the
> > sd had errors so the kernel loaded from nand okay and then init
> > loaded but then subsequent programs or scripts loaded corrupt and
> > something locked up, so I used the power button.
> 
> Hmm, and then you booted from NAND and went on to repair the uSD card
> using the system booted from NAND ? Thanks, that's indeed a case where
> there's a visible difference, because we wouldn't even reach the point
> where neodog is running, yet the kernel isn't completely dead yet.
> 
> > Second time was when I was hacking the timers yesterday and
> > apparently I broke gettimeofday and one of the first processes hung
> > waiting for something, I used the power button (for kicks) and it
> > worked. (99% of the times I was just taking the battery out and
> > wouldn't mind doing it that time also)
> 
> You're very brave to do this kind of low-level hacking without a debug
> board ;-)
> 
> By the way, my solution for quickly resetting the Neo without too much
> physical effort is to just toggle the debug board reset:
> 
> http://svn.openmoko.org/developers/werner/dbgrst/
> 
> I almost always keep the debug board attached, since I don't want to
> miss any clues printed on the serial console, and I also like to copy
> and paste printks for later reference (which I couldn't do if I only
> had them on the screen).
> 
> > Something to consider is that Linux has something called SysRq key
> > for like 15 years and it's a similar concept.  It's something that
> > works at all times even after the kernel panicked and nobody doubts
> > its usefulness.
> 
> Yes, SysRq is pretty close to this. Even there, the low-level driver
> only provides the SysRq keycode, but it's higher-level code that
> decides what to do with it. But I take your point that this is still
> in the kernel, not in user space.
> 
> How about the following compromise: we leave the power-down code in
> the kernel, but move it from the interrupt handler to a separate
> function (perhaps in a separate file as well) that just gets called
> on ONKEY/SECOND events and that's responsible for handling
> onkey_seconds and perhaps also PCF50633_F_PWR_PRESSED.
> 
> That makes it easier to remove/restructure/etc. it in case there are
> objections or if a future use of the PCF50633 by us or others does
> not agree with this specific emergency shutdown mechanism.
> pcf50633_work should be broken down into more manageable pieces
> anyway, see CodingStyle, chapter 6.
> 
> Does that sound good ?

Yes, this looks good to me.