On Thu, Jan 14, 2010 at 11:36:25PM -0500, Andreas Dilger wrote: > On 2010-01-14, at 20:24, Dave Chinner wrote: >> On Thu, Jan 14, 2010 at 10:33:42AM -0500, Andreas Dilger wrote: >>> Sure, it is _possible_ to do this, but you miss the fact that there >>> are >>> many system monitoring tools that already scrape /var/log/messages >>> and >>> integrate with event managers. What you are suggesting is that every >>> such tool implement an extra, completely ad-hoc mechanism just for >>> monitoring the mount/unmount of filesystems on Linux. That doesn't >>> make >>> sense. >> >> We already report various events through a netlink interface, but not >> to the log files (e.g. quota warnings), so those system monitoring >> tools are already going to be missing interesting information. >> >> Using log files for system event notification used to be the only >> way to communicate such events. Now we have much more advanced and >> efficient mechanisms for notifications so I think we should use >> them. .... > However, there are many reasons why it still makes sense to do this: > - it is in plain text format. I can't recall the number of times > people were proposing crazy schemes to have a text interface to the > kernel (via /sys/blah, or /debugfs/blah) for things that are much > better suited to an ioctl, since they are largely handled by binaries > (applications), yet in the case where we have an existing plain-text > interface (dmesg and /var/log/messages) that are meant (at least > partly) for human consumption we are proposing a binary interface > - every system monitoring tool in existence has a /var/log/messages > scraping interface, because this is the lowest common denominator, > but I'd suspect that few/none have a netlink interface, or if they > do it probably can't be easily added to by a user A daemon that captures the events from netlink and writes them to syslog is all that is needed to support log file scraping monitoring tools. The message they scrape does not have to come from the kernel... > If we are going to propose adding a binary interface for kernel status > notification, then we should discuss a proper interface for such that > is a real improvement over what we have today. Things like having > proper error message numbers, error levels, subsystem identifiers, > timestamps, name=value status fields, not doing printf formatting in > the kernel, etc. Event notifications don't need this sort of complexity - classifying an event is something for the userspace side of the notification - it is the policy part of the equation. Different applications will do this differently. e.g. system monitoring might write it to syslog for the scraper to read, while a desktop subsystem might deliver it to a taskbar notification mechanism to generate a usre visible popup message. IMO, using printk() for such notifications provides none of the flexibility that modern systems require, but events can easily be used to support legacy methods of event reporting. Hence it seems to me like a no brainer to use events rather than printk for all new notifications.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
