All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: dedekind1@gmail.com
Cc: Tanya Brokhman <tlinder@codeaurora.org>,
	hujianyang@huawei.com, linux-mtd@lists.infradead.org,
	linux-arm-msm@vger.kernel.org,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] UBI: Extend UBI layer debug/messaging capabilities - cosmetics
Date: Mon, 10 Nov 2014 08:10:17 -0800	[thread overview]
Message-ID: <1415635817.8868.6.camel@perches.com> (raw)
In-Reply-To: <1415625297.22887.108.camel@sauron.fi.intel.com>

On Mon, 2014-11-10 at 15:14 +0200, Artem Bityutskiy wrote:
> On Mon, 2014-11-10 at 14:53 +0200, Tanya Brokhman wrote:
> > On 11/10/2014 2:18 PM, Artem Bityutskiy wrote:
> > > On Sun, 2014-11-09 at 13:06 +0200, Tanya Brokhman wrote:
> > >>
> > >>   /* Normal UBI messages */
> > >>   #define ubi_msg(ubi, fmt, ...) pr_notice("UBI-%d: %s:" fmt "\n", \
> > >> -                                        ubi->ubi_num, __func__, ##__VA_ARGS__)
> > >> +                               (ubi ? ubi->ubi_num : UBI_MAX_DEVICES), \
> > >> +                               __func__, ##__VA_ARGS__)
> > >>   /* UBI warning messages */
> > >>   #define ubi_warn(ubi, fmt, ...) pr_warn("UBI-%d warning: %s: " fmt "\n", \
> > >> -                                       ubi->ubi_num, __func__, ##__VA_ARGS__)
> > >> +                               (ubi ? ubi->ubi_num : UBI_MAX_DEVICES), \
> > >> +                               __func__, ##__VA_ARGS__)
> > >>   /* UBI error messages */
> > >>   #define ubi_err(ubi, fmt, ...) pr_err("UBI-%d error: %s: " fmt "\n", \
> > >> -                                     ubi->ubi_num, __func__, ##__VA_ARGS__)
> > >> +                               (ubi ? ubi->ubi_num : UBI_MAX_DEVICES), \
> > >> +                               __func__, ##__VA_ARGS__)
> > >
> > > Why did you make these changes? It is preferable to not add another 'if'
> > > statement to this macro to handle one or 2 cases - much bloat, little
> > > gain.
> > >
> > > Could we please avoid this?
> > 
> > I just wanted to be on the safe side and prevent this macro being called 
> > with ubi=NULL that may crash the system. If you still prefer the "if" 
> > removed will do.
> 
> On the other hand, these are macros, and this if gets duplicated in many
> places and translate into few additional assembly instructions per
> message.

The thing that will make these uses smaller is to
convert them to functions.

There is a lot of extra duplicated "UBI-%s <msg_type>: "
constant string .text added.

Using a function uses a single copy of each prefix.

The __func__ variable can also be removed.
__builtin_return_address(0) may be substituted to save
a few more bytes per instance.

Something like:

(prototype)
__printf(2, 3)
void ubi_warn(struct ubi *ubi, const char *fmt, ...);

(implementation)
__printf(2, 3)
void ubi_warn(struct ubi *ubi, const char *fmt, ...)
{
	struct va_format vaf;
	va_list args;
	int device;

	va_start(args, format);

	vaf.fmt = format;
	vaf.va = &args;

	if (!ubi)
		device = UBI_MAX_DEVICE;
	else
		device = ubi->ubi_num;

	pr_warn("UBI-%d warning: %pf: %pV",
		device, __builtin_return_address(0), &vaf);

	va_end(args);
}

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: dedekind1@gmail.com
Cc: Tanya Brokhman <tlinder@codeaurora.org>,
	linux-arm-msm@vger.kernel.org,
	open list <linux-kernel@vger.kernel.org>,
	hujianyang@huawei.com, linux-mtd@lists.infradead.org,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH] UBI: Extend UBI layer debug/messaging capabilities - cosmetics
Date: Mon, 10 Nov 2014 08:10:17 -0800	[thread overview]
Message-ID: <1415635817.8868.6.camel@perches.com> (raw)
In-Reply-To: <1415625297.22887.108.camel@sauron.fi.intel.com>

On Mon, 2014-11-10 at 15:14 +0200, Artem Bityutskiy wrote:
> On Mon, 2014-11-10 at 14:53 +0200, Tanya Brokhman wrote:
> > On 11/10/2014 2:18 PM, Artem Bityutskiy wrote:
> > > On Sun, 2014-11-09 at 13:06 +0200, Tanya Brokhman wrote:
> > >>
> > >>   /* Normal UBI messages */
> > >>   #define ubi_msg(ubi, fmt, ...) pr_notice("UBI-%d: %s:" fmt "\n", \
> > >> -                                        ubi->ubi_num, __func__, ##__VA_ARGS__)
> > >> +                               (ubi ? ubi->ubi_num : UBI_MAX_DEVICES), \
> > >> +                               __func__, ##__VA_ARGS__)
> > >>   /* UBI warning messages */
> > >>   #define ubi_warn(ubi, fmt, ...) pr_warn("UBI-%d warning: %s: " fmt "\n", \
> > >> -                                       ubi->ubi_num, __func__, ##__VA_ARGS__)
> > >> +                               (ubi ? ubi->ubi_num : UBI_MAX_DEVICES), \
> > >> +                               __func__, ##__VA_ARGS__)
> > >>   /* UBI error messages */
> > >>   #define ubi_err(ubi, fmt, ...) pr_err("UBI-%d error: %s: " fmt "\n", \
> > >> -                                     ubi->ubi_num, __func__, ##__VA_ARGS__)
> > >> +                               (ubi ? ubi->ubi_num : UBI_MAX_DEVICES), \
> > >> +                               __func__, ##__VA_ARGS__)
> > >
> > > Why did you make these changes? It is preferable to not add another 'if'
> > > statement to this macro to handle one or 2 cases - much bloat, little
> > > gain.
> > >
> > > Could we please avoid this?
> > 
> > I just wanted to be on the safe side and prevent this macro being called 
> > with ubi=NULL that may crash the system. If you still prefer the "if" 
> > removed will do.
> 
> On the other hand, these are macros, and this if gets duplicated in many
> places and translate into few additional assembly instructions per
> message.

The thing that will make these uses smaller is to
convert them to functions.

There is a lot of extra duplicated "UBI-%s <msg_type>: "
constant string .text added.

Using a function uses a single copy of each prefix.

The __func__ variable can also be removed.
__builtin_return_address(0) may be substituted to save
a few more bytes per instance.

Something like:

(prototype)
__printf(2, 3)
void ubi_warn(struct ubi *ubi, const char *fmt, ...);

(implementation)
__printf(2, 3)
void ubi_warn(struct ubi *ubi, const char *fmt, ...)
{
	struct va_format vaf;
	va_list args;
	int device;

	va_start(args, format);

	vaf.fmt = format;
	vaf.va = &args;

	if (!ubi)
		device = UBI_MAX_DEVICE;
	else
		device = ubi->ubi_num;

	pr_warn("UBI-%d warning: %pf: %pV",
		device, __builtin_return_address(0), &vaf);

	va_end(args);
}

  reply	other threads:[~2014-11-10 16:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-09 11:06 [PATCH] UBI: Extend UBI layer debug/messaging capabilities - cosmetics Tanya Brokhman
2014-11-09 11:06 ` Tanya Brokhman
2014-11-09 11:06 ` Tanya Brokhman
2014-11-10 12:18 ` Artem Bityutskiy
2014-11-10 12:18   ` Artem Bityutskiy
2014-11-10 12:53   ` Tanya Brokhman
2014-11-10 12:53     ` Tanya Brokhman
2014-11-10 13:14     ` Artem Bityutskiy
2014-11-10 13:14       ` Artem Bityutskiy
2014-11-10 16:10       ` Joe Perches [this message]
2014-11-10 16:10         ` Joe Perches
2014-11-10 14:29     ` Richard Weinberger
2014-11-10 14:29       ` Richard Weinberger
2014-11-11 13:32 ` Artem Bityutskiy
2014-11-11 13:32   ` 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=1415635817.8868.6.camel@perches.com \
    --to=joe@perches.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=hujianyang@huawei.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --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.