[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z7NRLmcWJFNkyHGN@li-4c4c4544-0047-5210-804b-b8c04f323634.ibm.com>
Date: Mon, 17 Feb 2025 09:09:34 -0600
From: Nick Child <nnac123@...ux.ibm.com>
To: David Laight <david.laight.linux@...il.com>
Cc: Simon Horman <horms@...nel.org>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, haren@...ux.ibm.com, ricklind@...ibm.com,
nick.child@....com, jacob.e.keller@...el.com
Subject: Re: [PATCH 1/3] hexdump: Implement macro for converting large buffers
Thank you David and Simon for testing and review!
On Sun, Feb 16, 2025 at 11:24:30AM +0000, David Laight wrote:
>
> I just changed the prototypes (include/linux/printk.h) to make both
> rowsize and groupsize 'unsigned int'.
> The same change in lib/hexdump.c + changing the local 'i, linelen, remaining'
> to unsigned int and it all compiled.
>
> FWIW that hexdump code is pretty horrid (especially if groupsize != 1).
>
Given this discussion and my own head-scratching, I think I will take a
closer look at hex_dump_to_buffer.
I was trying to avoid editing this function due the number of callers it
has across the kernel. But I think we can get away with keeping the
API (but change args to uint's) and editing the body of the function
to always iterate byte-by-byte, addding space chars where necessary. At the
cost of a few more cycles, this will allow for more dynamic values
for rowsize and groupsize and shorten the code up a bit. This would also
address the "Side question" in my cover letter. Will send a v3
regardless if I can figure that out or not.
The return value of hex_dump_to_buffer on error still irks me a bit but
I don't think that can easily be changed.
Thanks again!
Powered by blists - more mailing lists