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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 15 Jan 2010 05:44:01 -0600
From:	Mike Mestnik <cheako911@...il.com>
To:	Dave Chinner <david@...morbit.com>,
	Andreas Dilger <adilger@....com>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	Toshiyuki Okajima <toshi.okajima@...fujitsu.com>,
	"Theodore Ts'o" <tytso@....edu>, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org,
	"James C. Browne" <browne@...utexas.edu>
Subject: Re: [REPOST][PATCH][RFC] vfs: add message print mechanism for the 
	mount/umount into the VFS layer

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