Message-ID: <4EF27B85.9080801@am.sony.com>
Date:	Wed, 21 Dec 2011 16:36:21 -0800
From:	Tim Bird <tim.bird@...sony.com>
To:	Greg KH <gregkh@...e.de>
CC:	linux-embedded <linux-embedded@...r.kernel.org>,
	linux kernel <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>,
	john stultz <johnstul@...ibm.com>,
	Brian Swetland <swetland@...gle.com>,
	Kay Sievers <kay.sievers@...y.org>,
	Lennart Poettering <lennart@...ttering.net>
Subject: Re: RFC: android logger feedback request

On 12/21/2011 03:19 PM, Greg KH wrote:
> That all describes the current code, but you haven't described what's
> wrong with the existing syslog interface that requires this new driver
> to be written.  And why can't the existing interface be fixed to address
> these (potential) shortcomings?


>> One specific question I have is where is the most appropriate
>> place for this code to live, in the kernel source tree?
>> Other embedded systems might want to use this system (it
>> is simpler than syslog, and superior in some ways), so I don't
>> think it should remain in an android-specific directory.
> 
> What way is it superior?

Here are some ways that this code is superior to syslog:

Speed and overhead
------------------
syslogd requires a separate user-space process to manage
the log area, where this code does not.  The overhead
for any user-space process is at least 16K, and usually much
more than this (not including the size of the log storage
area).  On one of my embedded systems, where syslogd is
provided by busybox, the unique set size for syslogd
is 96K.  This code, built in to the Linux kernel is less
than 4K code and data (again, not including the size of
the log storage area).

To deliver a message to syslog requires a socket operation
and a few context switches.  With the logger code,
the operation is a file operation (writev) to kernel memory,
with only one context switch into and out of the kernel.

The open and write paths through the Linux kernel are
arguably more optimized than the networking paths.
This is a consideration since the log operations should
optimized for the "create-a-log-entry" case (the open/write
path), since logs are mostly written and almost never read
on production devices.

No dependence on persistent storage
-----------------------------------
syslogd requires either persistent storage to store the log,
or a network connection to an outside device.  Being
purely memory-based, the logger requires neither of these.
With logger, persistence of the log data is left to the
implementor.  In Android, the data is delivered over a USB
connection via adb or to the console as ascii text, using
logcat.  In other embedded systems, other mechanisms might
be used if long-term storage of the messages is desired.
With logger, there is no automatic notion of on-device
persistent storage for the log data.

No dependence on networking kernel code
---------------------------------------
The syslog communication mechanism requires sockets.  This
prevents one from configuring the kernel with no networking
support, which is sometimes done in embedded systems to save
size.

Simpler constraint on log size
------------------------------
The busybox syslog daemon uses a log rotation feature to constrain
the size of the log in persistent storage.  This is overly
cumbersome in both speed and complexity compared to the logger's
simple ring buffer.

Licensing
---------
The code implementing library and command line tool support
for this logger (in user space) is available under an Apache license,
rather than a GPL license, which is desirable for some vendors.

> Again, why not extend syslog?  Why not "fix"
> syslog if this really is a superior thing?

"extend" syslog would not really the the right
direction.  This system is simpler than syslog,
while simultaneously having at least one valuable
extra feature (separate log channels).

syslog has a standard set of interfaces in libc
and various syslogd implementations, which are
heavier weight in nature than what is provided here.
It is unclear that an attempt at reducing these attributes
(such as memory overhead, number of context switches,
dependence on persistent storage, and socket utilization) would
yield a system substantially different from the logger.

> How does this tie into Kay
> and Lennard's proposal for work in this area?

It does not tie in at all.

Kay and Lennart's proposal for "the Journal" creates
a more complex system than syslog, and handles a number
of new interesting use cases.  This system is on the
opposite side of the spectrum from the journal, towards
simplicity and reduced footprint and overhead.

 -- Tim

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists