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
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
