From: Joe Perches <joe@perches.com>
To: Petr Mladek <pmladek@suse.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 09:08:21 -0700 [thread overview]
Message-ID: <1493309301.18659.47.camel@perches.com> (raw)
In-Reply-To: <20170427151121.GX3452@pathway.suse.cz>
On Thu, 2017-04-27 at 17:11 +0200, Petr Mladek wrote:
> On Wed 2017-03-01 21:58:54, Joe Perches wrote:
> > On Thu, 2017-03-02 at 14:35 +0900, Sergey Senozhatsky wrote:
> > > 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.
[]
> > 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_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.
I believe EXPORT_SYMBOL functions have been modified
in the past, but don't have an example at hand.
> 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.
That might work.
> 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.
>
> :-(
Yeah, that too.
next prev parent reply other threads:[~2017-04-27 16:08 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
2017-04-27 16:08 ` Joe Perches [this message]
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=1493309301.18659.47.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.