From: "Life is hard, and then you die" <ronald@innovation.ch>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Henrik Rydberg <rydberg@bitmath.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Lukas Wunner <lukas@wunner.de>,
Federico Lorenzi <federico@travelground.com>,
linux-input <linux-input@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/4] lib/hexdump.c: factor out generic hexdump formatting for reuse.
Date: Wed, 27 Mar 2019 17:34:59 -0700 [thread overview]
Message-ID: <20190328003459.GG24753@innovation.ch> (raw)
In-Reply-To: <CAHp75VebbroyOt6DPnqKVk99RowZsxgjuHbi6HoXf-tAuZLMqA@mail.gmail.com>
On Wed, Mar 27, 2019 at 09:46:48AM +0200, Andy Shevchenko wrote:
> On Wed, Mar 27, 2019 at 3:49 AM Ronald Tschalär <ronald@innovation.ch> wrote:
> >
> > This introduces print_hex_dump_to_cb() which contains all the hexdump
> > formatting minus the actual printk() call, allowing an arbitrary print
> > function to be supplied instead. And print_hex_dump() is re-implemented
> > using print_hex_dump_to_cb().
> >
> > This allows other hex-dump logging functions to be provided which call
> > printk() differently or even log the hexdump somewhere entirely
> > different.
>
> No Sign-off?
Yeah, my screwup.
> In any case, don't do it like this. smaller non-recursive printf() is
> better than one big receursive call.
> When it looks like an optimization, it's actually a regression.
Not sure where you see recursion here - are you referring to the
callback approach? Since dev_printk() ends up calling printk with a
dictionary as well as additional formatting, vs print_hex_dump()'s
stright use of printk, this seemed like the best way accommodate
various possible ways of logging the messages. But as per below I
guess this is moot.
> And yes, debugfs idea is not bad.
So it seems like that is the consensus. As per my other response, I'll
do this then and leave the print_hex_dump() alone.
> P.S. Also check %*ph specifier.
Thanks!
Cheers,
Ronald
next prev parent reply other threads:[~2019-03-28 0:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-27 1:48 [PATCH v3 0/4] Add Apple SPI keyboard and trackpad driver Ronald Tschalär
2019-03-27 1:48 ` [PATCH v3 1/4] drm/bridge: sil_sii8620: depend on INPUT instead of selecting it Ronald Tschalär
2019-03-27 14:13 ` Andrzej Hajda
2019-03-28 0:07 ` Life is hard, and then you die
2019-03-28 11:48 ` Andrzej Hajda
2019-03-29 9:22 ` Life is hard, and then you die
2019-03-27 1:48 ` [PATCH v3 2/4] lib/hexdump.c: factor out generic hexdump formatting for reuse Ronald Tschalär
2019-03-27 7:46 ` Andy Shevchenko
2019-03-28 0:34 ` Life is hard, and then you die [this message]
2019-03-28 9:03 ` Andy Shevchenko
2019-03-28 10:29 ` Life is hard, and then you die
2019-03-27 1:48 ` [PATCH v3 3/4] driver core: add dev_print_hex_dump() logging function Ronald Tschalär
2019-03-27 2:37 ` Greg Kroah-Hartman
2019-03-28 0:28 ` Life is hard, and then you die
2019-03-28 5:29 ` Greg Kroah-Hartman
2019-03-28 10:27 ` Life is hard, and then you die
2019-03-28 11:29 ` Greg Kroah-Hartman
2019-03-28 12:30 ` Steven Rostedt
2019-04-02 2:47 ` Life is hard, and then you die
2019-04-02 6:33 ` Greg Kroah-Hartman
2019-04-07 1:46 ` Life is hard, and then you die
2019-04-08 12:07 ` Andy Shevchenko
2019-03-27 1:48 ` [PATCH v3 4/4] Input: add Apple SPI keyboard and trackpad driver Ronald Tschalär
2019-03-27 9:35 ` Andy Shevchenko
2019-03-27 18:45 ` Greg Kroah-Hartman
2019-03-27 19:15 ` Steven Rostedt
2019-03-27 19:22 ` Andy Shevchenko
2019-03-28 0:24 ` Life is hard, and then you die
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=20190328003459.GG24753@innovation.ch \
--to=ronald@innovation.ch \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=federico@travelground.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=rafael@kernel.org \
--cc=rostedt@goodmis.org \
--cc=rydberg@bitmath.org \
--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.