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 managethe log area, where this code does not. The overheadfor any user-space process is at least 16K, and usually muchmore than this (not including the size of the log storagearea). On one of my embedded systems, where syslogd isprovided by busybox, the unique set size for syslogdis 96K. This code, built in to the Linux kernel is lessthan 4K code and data (again, not including the size ofthe log storage area).To deliver a message to syslog requires a socket operationand 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 arearguably more optimized than the networking paths.This is a consideration since the log operations shouldoptimized for the "create-a-log-entry" case (the open/writepath), since logs are mostly written and almost never readon production devices.

No dependence on persistent storage-----------------------------------syslogd requires either persistent storage to store the log,or a network connection to an outside device. Beingpurely memory-based, the logger requires neither of these.With logger, persistence of the log data is left to theimplementor. In Android, the data is delivered over a USBconnection via adb or to the console as ascii text, usinglogcat. In other embedded systems, other mechanisms mightbe used if long-term storage of the messages is desired.With logger, there is no automatic notion of on-devicepersistent storage for the log data.No dependence on networking kernel code---------------------------------------The syslog communication mechanism requires sockets. Thisprevents one from configuring the kernel with no networkingsupport, which is sometimes done in embedded systems to savesize.Simpler constraint on log size------------------------------The busybox syslog daemon uses a log rotation feature to constrainthe size of the log in persistent storage. This is overlycumbersome in both speed and complexity compared to the logger'ssimple ring buffer.Licensing---------The code implementing library and command line tool supportfor 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 rightdirection. This system is simpler than syslog,while simultaneously having at least one valuableextra feature (separate log channels).

syslog has a standard set of interfaces in libcand various syslogd implementations, which areheavier 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) wouldyield 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" createsa more complex system than syslog, and handles a numberof new interesting use cases. This system is on theopposite side of the spectrum from the journal, towardssimplicity and reduced footprint and overhead.