All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Tanya Brokhman <tlinder@codeaurora.org>
Cc: dedekind1@gmail.com, ezequiel.garcia@free-electrons.com,
	linux-mtd@lists.infradead.org, linux-arm-msm@vger.kernel.org,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4] mtd: ubi: Extend UBI layer debug/messaging capabilities
Date: Mon, 20 Oct 2014 10:29:39 -0700	[thread overview]
Message-ID: <1413826179.19661.1.camel@perches.com> (raw)
In-Reply-To: <54453E3B.2050809@codeaurora.org>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Tanya Brokhman <tlinder@codeaurora.org>
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>
Subject: Re: [PATCH v4] mtd: ubi: Extend UBI layer debug/messaging capabilities
Date: Mon, 20 Oct 2014 10:29:39 -0700	[thread overview]
Message-ID: <1413826179.19661.1.camel@perches.com> (raw)
In-Reply-To: <54453E3B.2050809@codeaurora.org>

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.

  reply	other threads:[~2014-10-20 17:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-14 14:13 [PATCH v4] mtd: ubi: Extend UBI layer debug/messaging capabilities Tanya Brokhman
2014-10-14 14:13 ` Tanya Brokhman
2014-10-14 14:13 ` Tanya Brokhman
2014-10-14 14:16 ` Tanya Brokhman
2014-10-14 14:16   ` Tanya Brokhman
2014-10-14 14:33   ` Joe Perches
2014-10-14 14:33     ` Joe Perches
2014-10-14 15:07     ` Artem Bityutskiy
2014-10-14 15:07       ` Artem Bityutskiy
2014-10-14 16:05       ` Joe Perches
2014-10-14 16:05         ` Joe Perches
2014-10-20 13:51         ` Artem Bityutskiy
2014-10-20 13:51           ` Artem Bityutskiy
2014-10-20 16:54           ` Tanya Brokhman
2014-10-20 16:54             ` Tanya Brokhman
2014-10-20 17:29             ` Joe Perches [this message]
2014-10-20 17:29               ` Joe Perches
2014-10-14 14:39 ` Ezequiel Garcia
2014-10-14 14:39   ` Ezequiel Garcia
2014-10-14 15:09   ` Artem Bityutskiy
2014-10-14 15:09     ` Artem Bityutskiy
2014-10-14 18:47     ` Ezequiel Garcia
2014-10-14 18:47       ` Ezequiel Garcia
2014-10-14 19:13       ` Joe Perches
2014-10-14 19:13         ` Joe Perches
2014-10-14 19:18         ` Ezequiel Garcia
2014-10-14 19:18           ` Ezequiel Garcia
2014-10-14 19:31           ` Joe Perches
2014-10-14 19:31             ` Joe Perches
2014-10-20 13:53             ` Artem Bityutskiy
2014-10-20 13:53               ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1413826179.19661.1.camel@perches.com \
    --to=joe@perches.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=tlinder@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.