Has anyone android working with andy-tracking?

Michael Trimarchi trimarchi at gandalf.sssup.it
Sun Feb 8 15:05:22 CET 2009


Andy Green wrote:
> Hash: SHA1
> Michael Trimarchi wrote:
>> 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?
> Werner isn't waiting on this to do anything :-)
> Michael, if this wakelock stuff is just a local addition you made and
> not part of android, it's better we try to get rid of it.
> If Google are creating it though, maybe they have a larger plan and we
> need to deal with that.
> Can you clarify where the wakelock code came from?
Wakelock are google code :).

> - -Andy
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> teYAmwfx45HJfdkJp5lnzeJnMoEVOlrL
> =wxz9

More information about the openmoko-kernel mailing list