Re: RFC: android logger feedback request

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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:
> 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?


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

[Index of Archives]     [Gstreamer Embedded]     [Linux MMC Devel]     [U-Boot V2]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux ARM Kernel]     [Linux OMAP]     [Linux SCSI]

  Powered by Linux