Has anyone android working with andy-tracking?

Michael Trimarchi trimarchi at gandalf.sssup.it
Sun Feb 8 11:17:59 CET 2009


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
>
>   




More information about the openmoko-kernel mailing list