On Mon, 2019-06-24 at 22:37 -0700, Joe Perches wrote:
> On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> > From: Alastair D'Silva <alastair@xxxxxxxxxxx>
> >
> > With the wider display format, it can become hard to identify how
> > many
> > bytes into the line you are looking at.
> >
> > The patch adds new flags to hex_dump_to_buffer() and
> > print_hex_dump() to
> > print vertical lines to separate every N groups of bytes.
> >
> > eg.
> > buf:00000000: 454d414e 43415053|4e495f45
> > 00584544 NAMESPAC|E_INDEX.
> > buf:00000010: 00000000 00000002|00000000
> > 00000000 ........|........
> >
> > Signed-off-by: Alastair D'Silva <alastair@xxxxxxxxxxx>
> > ---
> > include/linux/printk.h | 3 +++
> > lib/hexdump.c | 59 ++++++++++++++++++++++++++++++++++++
> > ------
> > 2 files changed, 54 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/linux/printk.h b/include/linux/printk.h
> []
> > @@ -485,6 +485,9 @@ enum {
> >
> > #define HEXDUMP_ASCII BIT(0)
> > #define HEXDUMP_SUPPRESS_REPEATED BIT(1)
> > +#define HEXDUMP_2_GRP_LINES BIT(2)
> > +#define HEXDUMP_4_GRP_LINES BIT(3)
> > +#define HEXDUMP_8_GRP_LINES BIT(4)
>
> These aren't really bits as only one value should be set
> as 8 overrides 4 and 4 overrides 2.
This should be the other way around, as we should be emitting alternate
seperators based on the smallest grouping (2 implies 4 and 8, and 4
implies 8). I'll fix the logic.
I can't come up with a better way to represent these without making the
API more complex, if you have a suggestion, I'm happy to hear it.
>
> I would also expect this to be a value of 2 in your above
> example, rather than 8. It's described as groups not bytes.
>
> The example is showing a what would normally be a space ' '
> separator as a vertical bar '|' every 2nd grouping.
>
The above example shows a group size of 4 bytes, and
HEXDUMP_2_GRP_LINES set, with 2 groups being 8 bytes.
I'll make that clearer in the commit message.
--
Alastair D'Silva mob: 0423 762 819
skype: alastair_dsilva
Twitter: @EvilDeece
blog: http://alastair.d-silva.org
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
