Re: RFC: android logger feedback request
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On Thu, 22 Dec 2011, NeilBrown wrote:
On Wed, 21 Dec 2011 16:36:21 -0800 Tim Bird <tim.bird@xxxxxxxxxxx> wrote: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:It is certainly nice and simple. It really looks more like a filesystem than a char device though... though they aren't really files so much as lossy pipes. I don't think that's a problem though, lots of things in filesystems don't behave exactly like files. If you created a 'logbuf' filesystem that used libfs to provide a single directory in which privileged processes could create files then you wouldn't need the kernel to "know" the allowed logs: radio, events, main, system. The size could be set by ftruncate() (by privileged used again) rather than being hardcoded. You would defined 'read' and 'write' much like you currently do to create a list of datagrams in a circular buffer and replace the ioctls by more standard interfaces: LOGGER_GET_LOG_BUG_SIZE would use 'stat' and the st_blocks field LOGGER_GET_LOG_LEN would use 'stat' and the st_size field LOGGER_GET_NEXT_ENTRY_LEN could use the FIONREAD ioctl LOGGER_FLUSH_LOG could use ftruncate The result would be much the same amount of code, but an interface which has fewer details hard-coded and is generally more versatile and accessible.
That sounds better than what has been done in android, but it is still _far_ more limited than doing something that could be replaced by a fairly standard syslog daemon.
David Lang -- 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