[U-Boot] [PATCH RESEND 2/2 v2] lib: Add hexdump

[Tom Rini <trini@konsulko.com>]

On Sat, Jun 11, 2016 at 12:58:14AM +0300, ??????? ??????? wrote:
> Hi Tom,
> 
> 2016-06-11 0:39 GMT+03:00 Tom Rini <trini@konsulko.com>:
> > On Fri, Jun 10, 2016 at 11:51:20PM +0300, Alexey Brodkin wrote:
> >> Hi Tom,
> >>
> >> On Fri, 2016-06-10 at 15:37 -0400, Tom Rini wrote:
> >> > On Fri, Jun 10, 2016 at 03:31:30PM +0000, Langer, Thomas wrote:
> >> >
> >> > >
> >> > > Hello Alexey,
> >> > >
> >> > > This feature is already available in u-boot, please look for 'print_buffer'.
> >> >
> >> > ... make this a candidate for moving over to the linux kernel way?
> >>
> >> Could you please elaborate here a little bit?
> >> I didn't quite understood what do you propose really...
> >> Switch in U-Boot to kernel's hexdump or send patches with U-Boot's
> >> print_buffer to LKML?
> >
> > OK, to be clear and answer both emails, we should:
> 
> I'm sorry but again I cannot understand your proposal completely :)
> 
> > a) Only add the new header when calling the new function
> 
> What do you mean here?

No <hexdump.h> in <common.h> and only add <hexdump.h> when the C file is
calling a related function.

> > b) Add further parts to the series to convert current users of
> > print_buffer to these functions instead to reduce the mental changes one
> > makes when doing / reading U-Boot code vs Linux Kernel code.
> 
> Agree, that definitely make sense.
> But note there's a subtle issue in there. Kernel's implementation of
> print_hex_dump() assumes
> debug level which in case of Linux kernel makes perfect sense. But for
> U-Boot it is barely usable. So we may keep prototype of
> print_hex_dump() as it is just ignorihg KERN_XXX stuff
> or have U-Boot's own version with the first argument removed. But in
> latter case we'll need to
> update those "current users" of print_hex_dump.
> 
> Any thoughts?

Continue to ignore the level as you've done and then yes, we'll have to
make sure to carefully convert existing callers.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160610/210b8b29/attachment.sig>