Difference between revisions of "Mainline Android logger project"
(→Features) |
(→Features) |
||
Line 48: | Line 48: | ||
|average message size||?||?||?||need to measure | |average message size||?||?||?||need to measure | ||
|- | |- | ||
− | |RAM required for complete logger system||?||?||?||need to measure | + | |RAM required for complete logger system||?||?||?||need to measure (should include code space) |
|- | |- | ||
− | |flash or disk required for complete logger system||?||?||?||need to measure | + | |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 | |number of context switches per message||?||?||?||need to measure | ||
Line 58: | Line 62: | ||
|ability to store messages persistently on target||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|| | + | |ability to store messages persistently on host||yes*||no||yes |
+ | | | ||
+ | * adb logcat is builtin command for android | ||
+ | * you can use 'remote shell:dmesg >log.txt' on most embedded systems, but it's not really a design principle of logbuf | ||
+ | * syslog is built with remote message access integrated into the system | ||
|- | |- | ||
|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 | |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? | |ability to filter messages by tag||yes||no||?||does syslog require tagging, is grep used for syslog tagging? | ||
+ | |- | ||
+ | |ease of use||high - classes for logging available throughout Android system (CLI, C/C++, Java)||low - echo >/dev/kmsg (not integrated into user-space stack)||low - | ||
|} | |} | ||
Revision as of 09:07, 24 May 2011
Contents
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.
Competition (Threats)
What are the alternatives to the Android logger?
- logbuf (the kernel log buffer)
- syslog
What are the pros and cons of each system (see feature matrix below)
Performance
How much overhead does each logging system have?
How long does it take to write 1 million messages, for each of the above systems?
Size
What are the space requirements for each logging system?
Maintainability
How much does each system need to be maintained?
Configurability
What things can be configured at compile-time and run-time for each system?
Features
What features does each of the log systems have?
[Create a feature matrix here]
Attribute | logger | logbuf | syslog | Notes |
---|---|---|---|---|
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 - classes for logging available throughout Android system (CLI, C/C++, Java) | low - echo >/dev/kmsg (not integrated into user-space stack) | low - |
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
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?
- log
- logwrapper
- logsync
- 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