> -----Original Message-----
> From: Geert Uytterhoeven <[email protected]>
> Sent: Monday, 13 May 2019 5:01 PM
> To: Alastair D'Silva <[email protected]>
> Cc: [email protected]; Jani Nikula <[email protected]>; Joonas
> Lahtinen <[email protected]>; Rodrigo Vivi
> <[email protected]>; David Airlie <[email protected]>; Daniel Vetter
> <[email protected]>; Dan Carpenter <[email protected]>; Karsten
> Keil <[email protected]>; Jassi Brar <[email protected]>; Tom
> Lendacky <[email protected]>; David S. Miller
> <[email protected]>; Jose Abreu <[email protected]>; Kalle
> Valo <[email protected]>; Stanislaw Gruszka <[email protected]>;
> Benson Leung <[email protected]>; Enric Balletbo i Serra
> <[email protected]>; James E.J. Bottomley
> <[email protected]>; Martin K. Petersen <[email protected]>;
> Greg Kroah-Hartman <[email protected]>; Alexander Viro
> <[email protected]>; Petr Mladek <[email protected]>; Sergey
> Senozhatsky <[email protected]>; Steven Rostedt
> <[email protected]>; David Laight <[email protected]>; Andrew
> Morton <[email protected]>; Intel Graphics Development <intel-
> [email protected]>; DRI Development <dri-
> [email protected]>; Linux Kernel Mailing List <linux-
> [email protected]>; netdev <[email protected]>;
> [email protected]; linux-wireless <[email protected]>;
> scsi <[email protected]>; Linux Fbdev development list <linux-
> [email protected]>; driverdevel <[email protected]>; Linux
> FS Devel <[email protected]>
> Subject: Re: [PATCH v2 3/7] lib/hexdump.c: Optionally suppress lines of
> repeated bytes
> 
> Hi Alastair,
> 
> Thanks for your patch!

And thanks for your politeness :)

> 
> On Wed, May 8, 2019 at 9:04 AM Alastair D'Silva <[email protected]>
> wrote:
> > From: Alastair D'Silva <[email protected]>
> >
> > Some buffers may only be partially filled with useful data, while the
> > rest is padded (typically with 0x00 or 0xff).
> >
> > This patch introduces a flag to allow the supression of lines of
> > repeated bytes,
> 
> Given print_hex_dump() operates on entities of groupsize (1, 2, 4, or 8)
> bytes, wouldn't it make more sense to consider repeated groups instead of
> repeated bytes?

Maybe, it would mean that subsequent addresses may not be a multiple of rowsize 
though, which is useful.

> > which are replaced with '** Skipped %u bytes of value 0x%x **'
> 
> Using a custom message instead of just "*", like "hexdump" uses, will require
> preprocessing the output when recovering the original binary data by
> feeding it to e.g. "xxd".
> This may sound worse than it is, though, as I never got "xxd" to work without
> preprocessing anyway ;-)

I think showing the details of the skipped values is useful when reading the 
output directly. In situations where binary extracts are desired, the feature 
can always be disabled.

-- 
Alastair D'Silva           mob: 0423 762 819
skype: alastair_dsilva     msn: [email protected]
blog: http://alastair.d-silva.org    Twitter: @EvilDeece



_______________________________________________
devel mailing list
[email protected]
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to