All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Joe Perches <joe@perches.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.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: Thu, 27 Apr 2017 17:11:21 +0200	[thread overview]
Message-ID: <20170427151121.GX3452@pathway.suse.cz> (raw)
In-Reply-To: <1488434334.2179.1.camel@perches.com>

On Wed 2017-03-01 21:58:54, Joe Perches wrote:
> 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

BTW: The above mentioned commit adds one argument to
vprintk_default(). But the symbol is exported. I am
not sure if we could break the API.

We might need to create alternative vprintk_* functions
(called vlprintk_* or so) that would have the extra parameter.
And call them from the existing vprintk_* ones. Sigh.

Also note that we might need to pass more information
via the extra parameter, for example, KERN_ERR + KERN_CONT.

> 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

Same here. We should avoid the recursion.

Best Regards,
Petr

  reply	other threads:[~2017-04-27 15:11 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
2017-04-27 15:11     ` Petr Mladek [this message]
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=20170427151121.GX3452@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --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.