[Ce-android-mainline] logger update - jan 25

Tim Bird tim.bird at am.sony.com
Wed Jan 25 19:01:37 UTC 2012

Hi all,

Here's an update on what I'm doing with logger recently.

== Executive Summary ==
I've ported the user-space tools to non-Android and
started working on tweaks to the existing driver.

In parallel, I'm investigating suggestions for coalescing
the logger into the kernel log buffer plus junk on the
side (for multiple log channels).

== The gory details ==
I've ported liblog, log and logcat from Android (bionic) to glibc.

This might sound trivial (and I was expecting it to be so...),
but I ran into problems with differences in kernel header files
and glibc compatibility.  I ended up using a glibc from an
internal Sony distribution, and statically linking it.  So now
I've got these 2M binaries, which is sure to mess up my performance
measurements somewhat - but I'll try to fix that later.  In
any event, it's working, and I can use this to build a test harness
to measure performance and evaluate API/ABI alternatives.
I'm running this on Angstrom on a Panda board.  It's a bit
weird to see logcat output on a non-Android system, but it's
fun to see it work.

Eventually, I'll need to go back and get a parallel test setup
on Android as well.

I started work on some of the low-hanging issues for existing
driver source cleanups, as suggested by Android Morton.
See sub-section [13] at:

On that page, I've tried to capture all the suggestions and comments
that were made in the December LKML discussion.

The key here in the short term is that any changes made to the existing
driver need to be REALLY well validated, so that Google does not feel
that they need to turn off the logger driver in staging and replace with
their own version to avoid regressions.  In other words, any changes
need to leave it working exactly like the current logger driver, for now.
(Or get Google approval, so they are to blame if something blows up :-)

Because of this, I am going quite slowly, and validating code at the
assembly level to make sure nothing has changed.

With respect to this, I have found one thing that I didn't expect.
Andrew Morton said that the 'inline' attribute on small functions
is not needed, since the compilers generaly do the right thing with them.
My experience with a gcc 4.2.1 ARM cross compiler is different.
If I don't specify 'inline', then the code does NOT get inlined
This is for a very simple one-line function, where the call
overhead is larger than the code to execute the function.

Am I missing something, or is gcc just dumb?
I don't want to ignore Andrew, but I'm inclined to keep the 'inline'
attribute on some functions.

I plan to continue working on existing source code cleanups
for the next little while.  But I'll need a test setup that I
can trust (maybe that can do some stress testing), before I
start to do some of the more intrusive changes.

If anyone wants to help out and needs access to my code, I can
post it somewhere.  Just let me know.

 -- Tim

Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment

More information about the Ce-android-mainline mailing list