[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111221231956.GB23859@suse.de>
Date: Wed, 21 Dec 2011 15:19:56 -0800
From: Greg KH <gregkh@...e.de>
To: Tim Bird <tim.bird@...sony.com>
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 Wed, Dec 21, 2011 at 02:59:15PM -0800, Tim Bird wrote:
> Hi all,
>
> I'm looking for feedback on the Android logger code, to see what
> it would take to make this code acceptable for inclusion in
> the mainline kernel.
>
> Information about the features of Android logging system
> can be found at: http://elinux.org/Android_Logging_System
>
> This system creates a new system-wide logging service, in
> the kernel, for user-space message. It is more comparable
> to syslog than to the kernel log buffer, as it holds only
> user-space messages. It is optimized for write
> performance, since most of the time the log is written to
> and never read. It creates multiple log channels, to prevent
> an abundance of log messages in one channel from overwriting
> messages in another channel. The log channels have sizes
> fixed at kernel compile-time.
>
> Log messages are stored in very simple in-kernel buffers, that
> overflow old messages upon wrapping. A fixed set of attributes
> (pid, tid, timestamp and message), is kept for each message.
> By convention, Android puts a message priority and context tag
> into each message.
>
> In Android, this system uses a fixed set of device nodes with
> well-known names: /dev/log/main, /dev/log/events, /dev/log/radio
> and /dev/log/system.
>
> Operations on the log are done via a character device, using
> standard file operations and some ioctls.
>
> The code for this is below (I've moved it from linux-next
> drivers/staging/android for my own testing).
>
> Please let me know what issues you see with this code.
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? Again, why not extend syslog? Why not "fix"
syslog if this really is a superior thing? How does this tie into Kay
and Lennard's proposal for work in this area?
thanks,
greg k-h
--
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