* Greg KH - [http://driverdev.linuxdriverproject.org/pipermail/devel/2011-May/016658.html "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 warrented the creation of the android logger code in the first place."]

== Project task list ==

== Project task list ==

Revision as of 08:16, 8 June 2011

This page is for managing information related to the "Mainline Android Logger" project
of the CE Workgroup.

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?

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?

Size

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?

Maintainability

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?

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

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

ability to filter messages by tag

yes

no

?

does syslog require tagging, is grep used for syslog tagging?

ease of use

high

low

medium

Android has facilities for logging available throughout the system (CLI, C/C++, Java), as well as good tool integration for readout and filtering