Werner Almesberger wrote:
Andy Green wrote:
They're not so scary if they properly default to not impacting suspend
and resume in the case it's not Android running.
Hmm, but do we (Linux) really want to have an "Android mode" for
the kernel ? I very much doubt even Android would want this sort
of dichotomy.
I could imagine it's
quite useful to be able to be sure some complex transaction or event is
protected against suspend / resume and atomic for it, since otherwise
it's kind of like FIQ just blasting in there when it feels like it.
It certainly is useful for applications to be able to veto suspend
during critical activities. The question is just whether the kernel
is the right place to implement mechanisms to keep applications out
of each other's hair at such a high level. The suspend operation may
be very low-down but the decisions that lead to it aren't.
I'm agreee with you, and I think that the right place is user space at the
end.
In our (Openmoko) case, we have the framework that can take care of
such things. I would expect Android to have some means to coordinate
what its user space does as well.
Moving the lock support in the user space is the correct way, but It can be
done in next weeks, and maybe now having one config for all kernel, but
activate android with a bootup variable, instead a configuration option.
Moving the wakelock in user space is not difficult, they are
on a rbtree and can be with timeout or not, I just review the interaction
with console and framebuffer, because there are two other support
earlyconsolesuspend
and earlyfbsuspend if I remember. Werner can you wait such times for a
complete report?
Michael
- Werner
