Neo Freerunner PMU Status

[Werner Almesberger]

Andy Green wrote:
> Busybox init sure didn't spawn it... it must just
> for accounting it marks it up as child of PID #1 when nothing real
> occupies PID #1 yet.

PID 1 is also the precursor if init. It's the parent whose pending
signals get checked there, not the child. The child starts with its
signals cleared.

> Anyway this issue doesn't come from JFFS2, if that isn't the
> first kernel thread to behave that way and get aborted, then we solved
> nothing by that.

Yup, it would affect other kernel threads as well, if they're
unfortunate enough to try to launch at that time. That's why I wrote
"hack", because it would probably make the problem go away, but we
may meet it again later ;-)

> What we really wanted was to let *busybox init* have an advance warning
> of power loss so it can go down in an orderly way.

Yes, perhaps we could just have a sysfs file that controls whether
we send that signal or not. Default would be "off". When turning it
on, we'd check if we're in that problem situation, and generate the
signal, if necessary.

> -- and we might not make it through all that because we have
> genuine low battery!

Yes, but we still need to distinguish running out of battery power
from trying to start with an empty battery. So perhaps the immediate
power down would be a an option if the sysfs file says "off".
However, since we already made it this far, we may also decide to
just let it run until init can take over. (Which would then flip
the sysfs switch, and get itself killed.)

How does that sound ?

In any case, I think we have two issues here:

1) We (OpenMoko) try to kill init unusually early, which widens that
   window in which that problem can happen, and thus we actually see
   it.

2) That fork logic is probably not what we (Linux kernel) want to do
   for "trusted" threads in general.

- Werner