Re: RFC: android logger feedback request

[Greg KH <gregkh@suse.de>]

On Wed, Dec 21, 2011 at 06:34:08PM -0800, Brian Swetland wrote:
> The goals behind the logger driver have been:
> - keep userland and kernel logging separate (so that spammy userland
> logging doesn't make us lose critical kernel logs or the other way
> round)

Wouldn't a simple userspace daemon solve this, writing the data to a
ramfs file?

> - make log writing very inexpensive -- avoid having to pass messages
> between processes (more critical on ARM9 platforms where this implied
> extra cache flushing), avoid having to make several syscalls to write
> a log message (getting time of day, etc), and so on

ramfs?

> - make log writing reliable -- don't trust userland to report its
> timestamp, PID, or to correctly format the datagrams, etc

existing userspace printk tty driver?

> - allow a log watching process (logcat) to easily pull data from all
> logs at once

what do you mean by "at once"?

> - avoid committing a vast amount of memory to logging

memory where, in code or in the data being logged?

> - try to prevent clients from spamming each other out of log space
> (only successful on a coarse granularity right now with the
> main/system/radio/events logs)
> - ensure logs are not lost at the moment an app crashes

Which logs?

> On one hand, having each app (per PID) be able to create their own
> logs up to a specified size limit could be really useful and is
> something we've kicked around -- for one it would allow us to avoid
> the ever present request from userspace developers to increase the log
> size because of too much log spam ("reduce log spam" never seems to be
> an answer that makes them happy) -- but we haven't come up with a
> reasonable plan for dealing with "well if we allow 16KB of log per app
> and the user installs 100 apps, they may be pinning up to 1.6MB of ram
> worst case", and so on.

I think the userspace printk and syslog might already handle most of
this today.  Tim, care to look into that and see if it does or not?

thanks,

greg k-h