Mainline Android logger project
This page is for managing information related to the "Mainline Android Logger" project of the CE Workgroup. This is part of the Android Mainlining Project.
- 1 Android logger issues
- 2 Discussions
- 3 Project task list
- 4 History
Android logger issues
This section describes some attributes of the Android logger code, which are relevant for mainlining the code into Linux. Let's use a modified SWOT (Strengths, Weaknesses, Opportunities, Threats) analysis for strategic planning to mainline this code.
To find the logger's strengths and weaknesses, lets research and provide information and hard numbers for how it compares with existing logging alternatives.
What are the alternatives to the Android logger?
- logbuf (the kernel log buffer)
- apparently, systemd uses
- "the journal" - a new logging system for systemd (by Lennart Poettering)
- see systemd journal for a good discussion of problems with syslog
- Neil Brown's log-pipe idea
- I thought this one was interesting. See: Neil Brown's message about this on LKML
- Arnd Bergmann's tmpfs idea
- See this message
What are the pros and cons of each system (see feature matrix below)
Does the system or proposed alternative currently exist?
How much work would it be to create it?
How much work would it be to test it to confirm that it had the same semantics as current Android logger?
How much overhead does each logging system have?
How long does it take to write 1 million messages, for each of the above systems?
How many context switches are required to log a single message?
How long is each message, on average?
How many data copies are performed for each message?
What is the average time to write each message, from the caller's perspective?
What are the space requirements for each logging system?
what is the code footprint in the kernel?
What is the data footprint in the kernel?
What is the code footprint in user-space?
What is the data footprint in user-space?
Are any other modules are required solely to support logging?
What is the size required in persistent storage?
Can the size be limited (at compile-time?, at boot-time?, at run-time?)
Can the size be adjusted (at boot-time?, at run-time?)
Given default sizes, and expected logging rates, how much time does each system record?
How much does each system need to be maintained?
How many changes have been made to the each system in the last 3 years?
Are any significant changes expected in the future?
What things can be configured at compile-time and run-time for each system?
What features does each of the log systems have?
|multiple channels||yes||no||no?||allows for separation of data to prevent overrun|
|can limit space used||yes||yes||?|
|cost to write 1M messages||?||?||?||need to benchmark|
|average cost to write a message||?||?||?||need to measure|
|average message size||?||?||?||need to measure|
|RAM required for complete logger system||?||?||?||need to measure (should include code space)|
|amount of flash or disk required for complete logger system||?||?||?||need to measure (should include code space)|
|user daemon required?||no||no||yes||syslog requires syslogd|
|networking required||no||no||no*||syslog requires network for some remote features|
|number of context switches per message||?||?||?||need to measure|
|logs both kernel and user messages?||no||no||yes?||klogd puts logbuf messages into syslog?|
|ability to store messages persistently on target||no||no*||yes||klogd puts logbuf messages into syslog?|
|ability to store messages persistently on host||yes*||no||yes||
|integrated into existing debug tools||yes||no?||no?||I don't know of anything but target-side tools (dmesg, cat /var/log) that "know" about logbuf and syslog|
|ability to filter messages by tag||yes||no||?||does syslog require tagging, is grep used for syslog tagging?|
|ease of use||high||low||medium||
|tool support||toolbox, adb||busybox, standalone dmesg, klogd||busybox, standalone logger, syslogd|
|API stability||high*||high||high||One change, to add 'system' channel in Android, in last 3 years. System channel separates system log messages from application log messages to prevent buffer exhaustion in case of a chatty application.|
Here are some questions about how the systems could be integrated:
- What features could each log system have, if extended?
- Would extension to an existing system interfere with it's current primary purpose?
- For each change contemplated, can it be implemented to minimize the impact to existing code?
Barriers to entry as is (Weaknesses)
Does logger duplicate functionality that exists elsewhere? Does it make sense to extend an existing system, rather than implement a new system?
What are barriers to entry:
- use of ioctl?
- hardcoded number of log channels
- other style issues?
- longterm maintainer?
Attractive features of logger as is (Strengths)
What are the differentiating features of logger, compared to alternatives?
- minimal context switches for logging
- use of ring buffer automatically limits log size
- log is in memory (no cost to store unused log messages)
- all messages are tagged
- all messages have priority
- all messages have timestamp
- user-space program to filter messages by tag
- channel selection by user-space policy
This section has notes about discussions with the community kernel developers and with Google engineers, with regards to mainlining this code
Google engineer requests/questions
- Google doesn't want to change their class libraries or debug system
- These have already shipped to developers and are integrated into other tools (eclipse log viewer)
- the Android system and over 200,000 applications already use the existing classes
- (So, can changes be made "under the hood" without changing the existing user interface?)
- Google requests that any changes submitted to mainline also be placed in their kernel repository (or Gerrit review queue), so they can see them when they do merges and are not caught off guard.
- I'm not sure the detailed steps required to perform this
- Question: Why did Google write their own code, instead of using syslog?
- Was it simply expedience, lack of familiarity with syslog, or are there specific reasons they wrote a new system (missing features, etc.)?
- Greg KH - "At worse case, all of the code could go away and the normal logging interface be used, after it would be fixed up to handle the special needs that warranted the creation of the android logger code in the first place."
- Alessio - In my opinion syslog shouldn't be compared with neither Android's logger nor logbuf because:
- Buggy syslog implementation (or future changes) could shutdown the entire log infrastructure (logger and logbuf aren't supposed to change a lot in future)
- Logbuf and logger don't require writeable file system access which is mandatory for syslog. A no-writeable files-system (or a file-system which allow only few writes) is a common situation in embedded world.
- Logbuf and logger don't require maintenance work (no rotate, compress or purge old log files). A mandatory feature in consumer devices.
The advantages of logger over logbuf are:
- Logger's logs are shared among a unknown number of user space programs
logbuf are writable only by kernel itself
- Logger's log are separated: An wild user space program couldn't fill up all logs.
- Write path in logger is optimized over all else
December 2011 LKML discussion
Here is the thread:
Notes on specific issues:
- logbuf code seems to do this now
- see systemd usage
Project task list
- Get needed hardware
- Make sure contractors have all required source code:
- AOSP, Android kernels, and logger code
- Identify and review code before submission
- identify possible mainline objections to code, and plan how to respond
- compare with alternatives
- compare and contrast logger code with kernel log buffer (e.g. dmesg vs. logcat)
- performance, features, size,
- compare and contrast logger code with syslog (syslogd, /var/log)
- compare and contrast logger code with kernel log buffer (e.g. dmesg vs. logcat)
- Submit code to LKML
- Respond to feedback received
- Add logger code to busybox?
- Should this be done first?
- What about logd_write.c code
- included in bionic - should be included in busybox directly, because it's missing in glibc?
- what about udev?
- should mainline Linux automatically create logger devices nodes?
- they are created by 'init' in Android systems
The proposals that led to this project are at: