On Thu, Jan 14, 2010 at 11:36:25PM -0500, Andreas Dilger wrote:

On 2010-01-14, at 20:24, Dave Chinner wrote:

quoted

On Thu, Jan 14, 2010 at 10:33:42AM -0500, Andreas Dilger wrote:

quoted

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@fromorbit.com