Re: [REPOST][PATCH][RFC] vfs: add message print mechanism for the mount/umount into the VFS layer

[Mike Mestnik <cheako911@gmail.com>]

On Fri, Jan 15, 2010 at 5:02 AM, Dave Chinner <david@fromorbit.com> 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@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html