mbox series

[00/13] display_options: Start to unify print_buffer() and hexdump

Message ID 20210317181840.3975687-1-sjg@chromium.org
Headers show
Series display_options: Start to unify print_buffer() and hexdump | expand

Message

Simon Glass March 17, 2021, 6:18 p.m. UTC 
At present we have two ways of showing a hex dump. Once has been in U-Boot
since the dawn of time and the other was recently added from Linux.

They both have their own unique features.

This series makes a few changes to bring them closer together. It also
adds support for logging a buffer, which is useful since it can put it
through the same log drivers as other logging output.

Also it adds tests, so we can check the behaviour.

The code-size impact of the main part of this series is 160 bytes on
Thumb2, which seems acceptable. However the final patch adds another 600
bytes or so, which is not.


Simon Glass (13):
  console: Report an error when output buffer is exhausted
  test: Detect when expect_str is too small
  test: Convert print tests to use ut framework
  test: Add a test for print_buffer()
  display_options: Drop two spaces before the ASCII column
  hexdump: Move API to header file
  hexdump: Add support for sandbox
  hexdump: Support any rowsize
  hexdump: Allow ctrl-c to interrupt output
  log: Drop log_nop() functions
  display_options: Split print_buffer() into two functions
  log: Add support for logging a buffer
  RFC: display_options: Use print_hex_dump() for print_buffer()

 common/console.c                  |  18 +-
 common/log.c                      |  30 ++++
 include/asm-generic/global_data.h |  16 +-
 include/console.h                 |   3 +-
 include/display_options.h         |  25 +++
 include/hexdump.h                 |  81 ++++++++-
 include/log.h                     |  49 +++--
 include/test/suites.h             |   1 +
 include/test/test.h               |   4 +-
 lib/display_options.c             | 124 ++++++++-----
 lib/hexdump.c                     | 104 +++--------
 test/cmd/mem_search.c             |  26 +--
 test/cmd_ut.c                     |   2 +
 test/dm/rtc.c                     |   9 +-
 test/log/log_test.c               |  27 +++
 test/print_ut.c                   | 286 ++++++++++++++++++++++++------
 test/ut.c                         |  55 +++++-
 17 files changed, 628 insertions(+), 232 deletions(-)

Comments

Tom Rini April 19, 2021, 1:42 p.m. UTC | #1 
On Thu, Mar 18, 2021 at 07:18:27AM +1300, Simon Glass wrote:

> At present we have two ways of showing a hex dump. Once has been in U-Boot
> since the dawn of time and the other was recently added from Linux.
> 
> They both have their own unique features.
> 
> This series makes a few changes to bring them closer together. It also
> adds support for logging a buffer, which is useful since it can put it
> through the same log drivers as other logging output.
> 
> Also it adds tests, so we can check the behaviour.
> 
> The code-size impact of the main part of this series is 160 bytes on
> Thumb2, which seems acceptable. However the final patch adds another 600
> bytes or so, which is not.

This seems good, and to set aside the RFC for now.  But it needs to be
rebased on master now as 12/13 doesn't apply (and I don't see the "why"
and just 1-11 fails to build for sandbox.  Thanks.
Simon Glass May 8, 2021, 2:38 a.m. UTC | #2 
Hi Tom,

On Mon, 19 Apr 2021 at 06:42, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Mar 18, 2021 at 07:18:27AM +1300, Simon Glass wrote:
>
> > At present we have two ways of showing a hex dump. Once has been in U-Boot
> > since the dawn of time and the other was recently added from Linux.
> >
> > They both have their own unique features.
> >
> > This series makes a few changes to bring them closer together. It also
> > adds support for logging a buffer, which is useful since it can put it
> > through the same log drivers as other logging output.
> >
> > Also it adds tests, so we can check the behaviour.
> >
> > The code-size impact of the main part of this series is 160 bytes on
> > Thumb2, which seems acceptable. However the final patch adds another 600
> > bytes or so, which is not.
>
> This seems good, and to set aside the RFC for now.  But it needs to be
> rebased on master now as 12/13 doesn't apply (and I don't see the "why"
> and just 1-11 fails to build for sandbox.  Thanks.

Unfortunately I forgot about this one. I'll send it again. I still
think we should hold off on the RFC patch due to the code-size
problem, although I'm not sure it can be solved.

Regards,
Simon