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.
next prev parent 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.