All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [RFC PATCH] printk: Make functions of pr_<level> macros
Date: Wed, 01 Mar 2017 21:58:54 -0800	[thread overview]
Message-ID: <1488434334.2179.1.camel@perches.com> (raw)
In-Reply-To: <20170302053509.GA398@jagdpanzerIV.localdomain>

On Thu, 2017-03-02 at 14:35 +0900, Sergey Senozhatsky wrote:
> Hello Joe,
> 
> On (02/28/17 19:17), Joe Perches wrote:
> > Can save the space that the KERN_<LEVEL> headers require.
> > 
> > The biggest negative here is the %pV use which needs
> > recursion and adds stack depth.
> > 
> > $ size vmlinux.o* (defconfig, x86-64)
> >    text     data     bss      dec     hex  filename
> > 12586135  1909841  777528 15273504  e90e20 vmlinux.o.new
> > 12590348  1909841  777528 15277717  e91e95 vmlinux.o.old
> 
> interesting. 4K.

Yeah, more when more calls are converted,

Maybe more like 12k, still the goal is to 
create singletons for the pr_fmt prefixes
and whatever __func__ uses that are most
common via a SOH + flag and using
__builtin_return_address where possible and
appropriate.  That could shrink another 10k
or so.

> [..]
> > +#define define_pr_func(func, level)			\
> > +asmlinkage __visible int func(const char *fmt, ...)	\
> > +{							\ 
> > +	va_list args;					\
> > +	int r;						\
> > +	struct va_format vaf;				\
> > +							\
> > +	va_start(args, fmt);				\
> > +	vaf.fmt = fmt;					\
> > +	vaf.va = &args;					\
> > +							\
> > +	r = printk(level "%pV", &vaf);			\
> > +							\
> > +	va_end(args);					\
> > +							\
> > +	return r;					\
> > +}							\
> 
> hm. that's really hacky (which is a compliment) and a bit complicated.
> my quick thought was to tweak vprintk_emit() for 'facility != 0' so it
> could get loglevel (and adjust lflags) from the passed level, not from
> the text, and then do something like this


> #define define_pr_func(func, level) asmlinkage __visible int func(const char *fmt, ...)
> {
> 	va_start(args, fmt);
> 	r = vprintk_emit(level[0], level[1], NULL, 0, fmt, args);
> 	va_end();
> }
> 
> but this won't do the trick. because func()->vprintk_emit() shortcut
> disables the printk-safe mechanism:
> 	func()->printk()->vprintk_func()->this_cpu(printk_context)::print()

That was what I had done originally a while ago
https://lkml.org/lkml/2016/6/23/652

Now the with "safe" version, it's a bit more complicated.

[stack depth can be high, ~400 bytes per recursion]

> dunno, at the moment I'm not really comfortable with %pV recursion
> for every pr_foo() call

Me neither really.  I'd much prefer a direct vprintk_emit.

  reply	other threads:[~2017-03-02  5:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-01  3:17 [RFC PATCH] printk: Make functions of pr_<level> macros Joe Perches
2017-03-02  5:35 ` Sergey Senozhatsky
2017-03-02  5:58   ` Joe Perches [this message]
2017-04-27 15:11     ` Petr Mladek
2017-04-27 16:08       ` Joe Perches
2017-04-27 16:28       ` Steven Rostedt

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=1488434334.2179.1.camel@perches.com \
    --to=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    /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.