Has anyone android working with andy-tracking?
andy at openmoko.com
Sun Feb 8 12:00:16 CET 2009
-----BEGIN PGP SIGNED MESSAGE-----
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
>> 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
> 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel