On Fri, Jan 15, 2010 at 5:02 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > 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... > klogd. Do we need another wheel? Moving this to userland as suggested seams like it would create more problems then it would solve. >> 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-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- 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
