[lttng-dev] Port to Android Linux

[Harald Gustafsson]

I only did a quick cleanup to be able to send the code as soon as
possible. This URCU patch is based on URCU 0.5.4, apologize that a few
of the diffs are indicating a new file when they actually have small
changes in them (I guess that Per did not use git properly at the
start). The UST patch is based on 0.13 (commit
317117239797a3609c1ec817a59bb3e70c9c1cba). Note that the URCU patch
contains BSD licensed code that we got from another source (the ARM
atomics).

Please see if it can be of any use, as I said the code is working but
have rough corners.

Regards,
  Harald

On Mon, Feb 27, 2012 at 10:41 AM, Harald Gustafsson <hgu1972 at gmail.com> wrote:
> Forgot to add a link to our short documentation of the work:
> https://docs.google.com/open?id=0B2aE_idi5Wt8MzZER1dLTGxRWmloU3ZZWEY1cUdzZw
>
> On Mon, Feb 27, 2012 at 9:46 AM, Harald Gustafsson <hgu1972 at gmail.com> wrote:
>> Hi all,
>>> Did anyone successfully port LTTng to Android Linux?
>>
>> Yes, we (Ericsson) have ported UST to Android and we have a fully
>> working but a bit rough code for it. It uses URCU and UST, we have
>> used it to trace for example pthread_mutex operation by LD_PRELOAD a
>> wrapper to bionic and hence it can handle that kind of load of traces.
>> A few weeks back I got clearance for contributing this back to LTTng
>> but I have not yet had time to upload, I will do that during the week.
>>
>> The rough part is the reimplementation of System V shared memory, we
>> use temporary files, this was a quick fix since using binder and ashm
>> would had involved larger changes to UST. The URCU changes are similar
>> to what Marek Vavrusa mailed (22th Jan) about URCU thread local
>> storage handling, this is needed since gcc with bionics can't do the
>> __thread. Also since the code we forked in May did not have proper
>> atomics for ARM we fixed that as well. One part can't be released it
>> is our trace clock implementation since it is device specific, but
>> since we tested on a pre-production system we did not need to be
>> concerned about security. We implemented the trace-clock by mmap the
>> memory (/dev/mem) having the device's clock-register and code read
>> that from user space directly.
>>
>> So I'll get back with a patch when I cleaned the code a bit.
>> Unfortunately, we don't have that much time to maintain this but would
>> gladly help anyone wanting to work with the code.
>>
>> /Harald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: urcu_androidport.patch
Type: text/x-patch
Size: 73939 bytes
Desc: not available
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20120227/ce615bfb/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ust_androidport.patch
Type: text/x-patch
Size: 130391 bytes
Desc: not available
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20120227/ce615bfb/attachment-0003.bin>