On Wed, Dec 21, 2011 at 05:32:36PM -0800, Tim Bird wrote: > On 12/21/2011 04:51 PM, Greg KH wrote: > > On Wed, Dec 21, 2011 at 04:36:21PM -0800, Tim Bird wrote: > >> On 12/21/2011 03:19 PM, Greg KH wrote: > > > Huh, I'm not talking about syslogd, I'm talking about the syslog(2) > > syscall we have. > > OK - switching gears. Since the kernel log buffer isn't normally > used to store use-space messages, I thought you were referring > to syslog(3) and the associated (logger(1) and syslogd(8)). The kernel log buffer has been storing userspace messages for a while now, look at your boot log on the latest Fedora and openSUSE releases (or any other distro using systemd for booting). > > This character interface seems very close to the syslog(2) api, but just > > done in a character interface, with ioctls, which also require userspace > > tools to manage properly, so I fail to see the big "gain" here. > > > > What am I missing? > > syslog(2) would more aptly be named klogctrl() (and it is in glibc) Maybe, but this is a kernel mailing list, we don't worry about glibc much here :) > There's currently no operation in sys_sylog (the kernel function > implementing syslog(2)) for writing to the log. The write operation > to the kernel log buffer is also done via a character interface > /dev/kmsg (via code in drivers/char/mem.c) This is actually very > similar to what the Android logger code does. Again, see above, this has been in the kernel for quite a while now... > But while the kernel log buffer has lots of similarities to the Android logger > there are some key differences which I think are important to isolate > from a user-space logging system. > > Here's a stream-of-consciousness dump of the differences: > > The printk interface in the kernel is almost always automatically drained > to the device console, at the time of the printk (after the message is dropped > into the log buffer itself). This extra operation is not needed for most > application-level messages that go into the log, and incurs extra overhead > in the log buffer code. > > The printk code is especially designed to be called from within any kernel > context (including interrupt code), and so has some locking avoidance code > paths and complexity that are not needed for code which handles strictly > user-space messages. > > Oddly enough, the printk code paths in the kernel can end up doing > a fair amount of print formatting, which can be time-consuming. The code > path in kmsg_writev() contains at least one kmalloc, which could fail > when running out of memory. The code path in the logger is much simpler, > consisting really of only a data copy. > > Timestamping is not automatically appended to messages going into the > kernel log buffer (but they can be optionally pre-pended, with control > configurable at runtime). They are represented > as ASCII text, which consumes a little more than twice the overhead of > a 32-bit binary field. PID and TID are not automatically preserved in > the log. The kernel keeps it's priority in text also, and has no convention > for contextual tagging. I'm not sure that we should change the > kernel log buffer to support structured binary data, in addition to the > free-form ASCII data that the kernel uses now. > > The kernel log buffer does not support separate channels for different > classes of log messages (indeed, there is only one channel, and it has > kernel messages). A new system call (or some backwards-compatible tweak > to the existing syslog(2) call would have to be added to support > a channel ID in order to support this. > > There *are* some benefits to intermingling the kernel log messages and the > user-space log messages, but I think they are outweighed by the > value in keeping these systems separate. There might be the opportunity > for code reuse, but I suspect we'd end up with about the same amount > of code increase overall (and possibly an additional syscall), and add > some unneeded complexity to the prink code path to accomplish it. Again, please see what we are already doing in the kernel and userspace, I think a lot of the above is already implemented. Which brings me back to my original question, what does this code do, that is not already present in the kernel, and why is a totally new interface being proposed for it? 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
