From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hans Reiser <reiser@namesys.com>
Subject: Re: [PATCH 3/5] reiserfs: rework reiserfs_warning
Date: Mon, 18 Jul 2005 18:01:26 -0700
Message-ID: <42DC50E6.3000604@namesys.com>
References: <20050718174230.GA23863@locomotive.unixthugs.org> <42DC03CC.5000502@namesys.com> <42DC4DAE.1020704@suse.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <reiserfs-list-return-25193-reiserfs=m.gmane.org@namesys.com>
list-help: <mailto:reiserfs-list-help@namesys.com>
list-unsubscribe: <mailto:reiserfs-list-unsubscribe@namesys.com>
list-post: <mailto:reiserfs-list@namesys.com>
Errors-To: flx@namesys.com
In-Reply-To: <42DC4DAE.1020704@suse.com>
List-Id: <reiserfs-devel.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: Jeff Mahoney <jeffm@suse.com>
Cc: ReiserFS List <reiserfs-list@namesys.com>

Jeff Mahoney wrote:

> Hans Reiser wrote:
>
> >Jeff, thanks so kindly for cleaning all this up, it must have been very
> >tedious, so extra thanks for it.
>
> >I will now quibble about some trivia....
>
> >Hans
>
> >Jeff Mahoney wrote:
>
> >>ReiserFS warnings can be somewhat inconsistent.
> >>In some cases:
> >>* a unique identifier may be associated with it
> >>* the function name may be included
> >>* the device may be printed separately
> >>
> >>This patch aims to make warnings more consistent. reiserfs_warning()
> prints
> >>the device name, so printing it a second time is not required. The
> function
> >>name for a warning is always helpful in debugging, so it is now
> automatically
> >>inserted into the output. Hans has stated that every warning should have
> >>a unique identifier. Some cases lack them, others really shouldn't
> have them.
> >>
> >>
> >What cases should not have them?
>
>
> I don't think that "routine" messages should have identifiers associated
> with them. I guess in a more exact sense, messages that are directly
> associated with user input, like mount option parsing, finding the
> superblock, an unfinished reiserfsck, or enabling CONFIG_REISERFS_CHECK.

I disagree, please don't remove identifiers.

>
> I guess a quick visual search for NO_ID in the patch would be the best
> way of expressing this. I could be convinced otherwise, and that's why I
> made two separate #defines for a missing id or deliberately no id.
>
> -Jeff
>
> --
> Jeff Mahoney
> SuSE Labs