From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtprelay0152.hostedemail.com ([216.40.44.152]
 helo=smtprelay.hostedemail.com)
 by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux))
 id 1XgGmU-0006Ov-4w
 for linux-mtd@lists.infradead.org; Mon, 20 Oct 2014 17:30:07 +0000
Message-ID: <1413826179.19661.1.camel@perches.com>
Subject: Re: [PATCH v4] mtd: ubi: Extend UBI layer debug/messaging capabilities
From: Joe Perches <joe@perches.com>
To: Tanya Brokhman <tlinder@codeaurora.org>
Date: Mon, 20 Oct 2014 10:29:39 -0700
In-Reply-To: <54453E3B.2050809@codeaurora.org>
References: <1413296037-22346-1-git-send-email-tlinder@codeaurora.org>
 <543D304C.5000607@codeaurora.org> <1413297205.3269.11.camel@joe-AO725>
 <1413299231.7906.101.camel@sauron.fi.intel.com>
 <1413302724.3269.18.camel@joe-AO725>
 <1413813074.7906.294.camel@sauron.fi.intel.com>
 <54453E3B.2050809@codeaurora.org>
Content-Type: text/plain; charset="ISO-8859-1"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Cc: dedekind1@gmail.com, linux-arm-msm@vger.kernel.org,
 open list <linux-kernel@vger.kernel.org>, linux-mtd@lists.infradead.org,
 ezequiel.garcia@free-electrons.com, Richard Weinberger <richard@nod.at>,
 Brian Norris <computersforpeace@gmail.com>,
 David Woodhouse <dwmw2@infradead.org>
List-Id: Linux MTD discussion mailing list <linux-mtd.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-mtd>,
 <mailto:linux-mtd-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-mtd/>
List-Post: <mailto:linux-mtd@lists.infradead.org>
List-Help: <mailto:linux-mtd-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
 <mailto:linux-mtd-request@lists.infradead.org?subject=subscribe>

On Mon, 2014-10-20 at 19:54 +0300, Tanya Brokhman wrote:
> On 10/20/2014 4:51 PM, Artem Bityutskiy wrote:
> > On Tue, 2014-10-14 at 09:05 -0700, Joe Perches wrote:
> >> It's pretty trivial when all the lines are already
> >> being touched.
> >
> > OK, but then the same change should done in UBIFS, because it's
> > ubifs_msg() and so on macros are consistent with UBI macros. So I think
> > if this is done, then it is done separately for both UBI and UBIFS.
[]
> We have similar patch for ubifs as well, one that adds ubi number to all 
> ubifs messages. We just didn't get to sharing it yet.

[]

> I prefer not adding the "\n" to my patch unless Artem insists on it.

I tested a nearly completely automated conversion to use
functions ad %pV for ubifs_err/ubifs_warn while adding
'\n' to the uses. (converted ubifs_msg to ubifs_notice too)

It reduces the object size a couple percent.
(allyesconfig)

$ size fs/ubifs/built-in.o*
   text	   data	    bss	    dec	    hex	filename
 335548	  66040	 138064	 539652	  83c04	fs/ubifs/built-in.o.new
 353362	  65912	 138000	 557274	  880da	fs/ubifs/built-in.o.old

It's not any real quantity of work to redo after you
post your patch.

There are a few defects today with unnecessary newlines
with ubifs_<level> uses.

$ git grep -P '\bubifs_\w+\s*.*\\n' 062a08d6ad56da23209083748ea5e0f1ab65a0e7 -- fs/ubifs/
062a08d6ad56da23209083748ea5e0f1ab65a0e7:fs/ubifs/debug.c:      ubifs_msg("first node at %d:%d\n", zbr1->lnum, zbr1->offs);
062a08d6ad56da23209083748ea5e0f1ab65a0e7:fs/ubifs/debug.c:      ubifs_msg("second node at %d:%d\n", zbr2->lnum, zbr2->offs);
062a08d6ad56da23209083748ea5e0f1ab65a0e7:fs/ubifs/debug.c:      ubifs_err("cannot create \"%s\" debugfs file or directory, error %d\n",
062a08d6ad56da23209083748ea5e0f1ab65a0e7:fs/ubifs/debug.c:      ubifs_err("cannot create \"%s\" debugfs file or directory, error %d\n",

Some with pr_<level> uses too.