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
> >
> > With the wider display format, it can become hard to identify how
> > many
> > bytes into the line you are lookin
On Mon, 2019-06-24 at 22:01 -0700, Joe Perches wrote:
> On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> > From: Alastair D'Silva
> >
> > In order to support additional features, rename hex_dump_to_buffer
> > to
> > hex_dump_to_buffer_ext, and
On Mon, 2019-06-24 at 22:01 -0700, Joe Perches wrote:
> On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> > From: Alastair D'Silva
> >
> > Apologies for the large CC list, it's a heads up for those
> > responsible
> > for subsystems where a protot
On Mon, 2019-06-24 at 22:19 -0700, Joe Perches wrote:
> On Tue, 2019-06-25 at 15:06 +1000, Alastair D'Silva wrote:
> > The change actions Jani's suggestion:
> > https://lkml.org/lkml/2019/6/20/343
>
> I suggest not changing any of the existing uses of
> hex_dum
From: Alastair D'Silva
Similar to the previous patch, this patch separates groups by 2 spaces for
the hex fields, and 1 space for the ASCII field.
eg.
buf:: 454d414e 43415053 4e495f45 00584544 NAMESPAC E_INDEX.
buf:0010: 0002
From: Alastair D'Silva
Apologies for the large CC list, it's a heads up for those responsible
for subsystems where a prototype change in generic code causes a change
in those subsystems.
This series enhances hexdump.
These improve the readability of the dumped data in certain situations
(eg
From: Alastair D'Silva
This patch removes the hardcoded row limits and allows for
other lengths. These lengths must still be a multiple of
groupsize.
This allows structs that are not 16/32 bytes to display on
a single line.
This patch also expands the self-tests to test row sizes
up to 64
From: Alastair D'Silva
The overflow tests did not account for the situation where no
overflow occurs and len < rowsize.
This patch renames the cryptic variables and accounts for the
above case.
The selftests now pass.
Signed-off-by: Alastair D'Silva
---
lib/test_hexdump.c |
From: Alastair D'Silva
In order to support additional features, rename hex_dump_to_buffer to
hex_dump_to_buffer_ext, and replace the ascii bool parameter with flags.
A wrapper is provided for callers that do not need anything but a basic
dump.
Signed-off-by: Alastair D'Silva
---
drivers/gpu
From: Alastair D'Silva
The behaviour of hexdump groups is to print the data out as if
it was a native-endian number.
This patch tweaks the documentation to make this clear, and also
adds the HEXDUMP_RETAIN_BYTE_ORDER flag to allow groups of
multiple bytes to be printed without affecting
From: Alastair D'Silva
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:: 454d414e
From: Alastair D'Silva
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, which are replaced with '** Skipped %u bytes of value 0x%x **'
An inline
On Mon, 2019-06-24 at 22:01 -0700, Joe Perches wrote:
> On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> > From: Alastair D'Silva
> >
> > In order to support additional features, rename hex_dump_to_buffer
> > to
> > hex_dump_to_buffer_ext, and
On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
> On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> > From: Alastair D'Silva
> >
> > Apologies for the large CC list, it's a heads up for those
> > responsible
> > for subsystems where a protot
On Wed, 2019-06-19 at 17:35 -0700, Joe Perches wrote:
> On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote:
> > On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
> > > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> > > > From: Alastair D'Sil
On Mon, 2019-06-17 at 15:47 -0700, Randy Dunlap wrote:
> Hi,
> Just a comment style nit below...
>
> On 6/16/19 7:04 PM, Alastair D'Silva wrote:
> > From: Alastair D'Silva
> >
> > This patch removes the hardcoded row limits and allows for
> > oth
From: Alastair D'Silva
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:: 454d414e
From: Alastair D'Silva
Apologies for the large CC list, it's a heads up for those responsible
for subsystems where a prototype change in generic code causes a change
in those subsystems.
This series enhances hexdump.
These improve the readability of the dumped data in certain situations
(eg
From: Alastair D'Silva
In order to support additional features in hex_dump_to_buffer, replace
the ascii bool parameter with flags.
Signed-off-by: Alastair D'Silva
---
drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
drivers/isdn/hardware/mISDN/mISDNisar.c | 6
From: Alastair D'Silva
The overflow tests did not account for the situation where no
overflow occurs and len < rowsize.
This patch renames the cryptic variables and accounts for the
above case.
The selftests now pass.
Signed-off-by: Alastair D'Silva
---
lib/test_hexdump.c |
From: Alastair D'Silva
The behaviour of hexdump groups is to print the data out as if
it was a native-endian number.
This patch tweaks the documentation to make this clear, and also
adds the HEXDUMP_RETAIN_BYTE_ORDER flag to allow groups of
multiple bytes to be printed without affecting
From: Alastair D'Silva
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, which are replaced with '** Skipped %u bytes of value 0x%x **'
An inline
From: Alastair D'Silva
This patch removes the hardcoded row limits and allows for
other lengths. These lengths must still be a multiple of
groupsize.
This allows structs that are not 16/32 bytes to display on
a single line.
This patch also expands the self-tests to test row sizes
up to 64
On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> 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
From: Alastair D'Silva
Similar to the previous patch, this patch separates groups by 2 spaces for
the hex fields, and 1 space for the ASCII field.
eg.
buf:: 454d414e 43415053 4e495f45 00584544 NAMESPAC E_INDEX.
buf:0010: 0002
> -Original Message-
> From: Geert Uytterhoeven
> Sent: Monday, 13 May 2019 5:01 PM
> To: Alastair D'Silva
> Cc: alast...@d-silva.org; Jani Nikula ; Joonas
> Lahtinen ; Rodrigo Vivi
> ; David Airlie ; Daniel Vetter
> ; Dan Carpenter ; Karsten
> Keil ; Jassi Br
On Wed, 2019-05-08 at 17:58 -0700, Randy Dunlap wrote:
> On 5/8/19 12:01 AM, Alastair D'Silva wrote:
> > From: Alastair D'Silva
> >
> > Some buffers may only be partially filled with useful data, while
> > the rest
> > is padded (typically with 0x00 or 0xff
From: Alastair D'Silva
Apologies for the large CC list, it's a heads up for those responsible
for subsystems where a prototype change in generic code causes a change
in those subsystems.
This series enhances hexdump.
These improve the readability of the dumped data in certain situations
(eg
From: Alastair D'Silva
Similar to the previous patch, this patch separates groups by 2 spaces for
the hex fields, and 1 space for the ASCII field.
eg.
buf:: 454d414e 43415053 4e495f45 00584544 NAMESPAC E_INDEX.
buf:0010: 0002
From: Alastair D'Silva
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, which are replaced with '** Skipped %u bytes of value 0x%x **'
An inline
From: Alastair D'Silva
The overflow tests did not account for the situation where no
overflow occurs and len < rowsize.
This patch renames the cryptic variables and accounts for the
above case.
The selftests now pass.
Signed-off-by: Alastair D'Silva
---
lib/test_hexdump.c |
From: Alastair D'Silva
In order to support additional features in hex_dump_to_buffer, replace
the ascii bool parameter with flags.
Signed-off-by: Alastair D'Silva
---
drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
drivers/isdn/hardware/mISDN/mISDNisar.c | 6
From: Alastair D'Silva
The behaviour of hexdump groups is to print the data out as if
it was a native-endian number.
This patch tweaks the documentation to make this clear, and also
adds the HEXDUMP_RETAIN_BYTE_ORDER flag to allow groups of
multiple bytes to be printed without affecting
From: Alastair D'Silva
This patch removes the hardcoded row limits and allows for
other lengths. These lengths must still be a multiple of
groupsize.
This allows structs that are not 16/32 bytes to display on
a single line.
This patch also expands the self-tests to test row sizes
up to 64
From: Alastair D'Silva
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:: 454d414e
> -Original Message-
> From: David Laight
> Sent: Monday, 15 April 2019 8:21 PM
> To: 'Alastair D'Silva' ; 'Petr Mladek'
>
> Cc: 'Alastair D'Silva' ; 'Jani Nikula'
> ; 'Joonas Lahtinen'
> ; 'Rodrigo Vivi' ;
> 'David Airlie' ; 'Daniel Vetter' ; 'Karsten
&g
> From: Alastair D'Silva
> > Sent: 15 April 2019 11:29
> ...
> > I do, and I believe the choice of the output length should be in the
> > hands of the caller.
> >
> > On further thought, it would make more sense to remove the hardcoded
> > list of sizes a
> > > On Wed 2019-04-10 13:17:17, Alastair D'Silva wrote:
> > > > From: Alastair D'Silva
> > > >
> > > > With modern high resolution screens, we can display more data,
> > > > which makes life a bit easier when debugging.
> > >
> -Original Message-
> From: David Laight
> Sent: Monday, 15 April 2019 9:04 PM
> To: 'Alastair D'Silva' ; 'Petr Mladek'
>
> Cc: 'Alastair D'Silva' ; 'Jani Nikula'
> ; 'Joonas Lahtinen'
> ; 'Rodrigo Vivi' ;
> 'David Airlie' ; 'Daniel Vetter' ; 'Karsten
&g
> > > On Wed 2019-04-10 13:17:18, Alastair D'Silva wrote:
> > > > From: Alastair D'Silva
> > > >
> > > > Some buffers may only be partially filled with useful data, while
> > > > the rest is padded (typically with 0x00 or 0xff).
>
> -Original Message-
> From: Petr Mladek
> Sent: Monday, 15 April 2019 7:24 PM
> To: Alastair D'Silva
> Cc: 'Alastair D'Silva' ; 'Jani Nikula'
> ; 'Joonas Lahtinen'
> ; 'Rodrigo Vivi'
;
> 'David Airlie' ; 'Daniel Vetter' ;
'Karsten
> Keil' ; 'Jassi Brar' ;
> -Original Message-
> From: Petr Mladek
> Sent: Friday, 12 April 2019 11:48 PM
> To: Alastair D'Silva
> Cc: alast...@d-silva.org; Jani Nikula ;
Joonas
> Lahtinen ; Rodrigo Vivi
> ; David Airlie ; Daniel Vetter
> ; Karsten Keil ; Jassi Brar
> ; Tom Lendacky
> -Original Message-
> From: Petr Mladek
> Sent: Saturday, 13 April 2019 12:12 AM
> To: Alastair D'Silva
> Cc: alast...@d-silva.org; Jani Nikula ;
Joonas
> Lahtinen ; Rodrigo Vivi
> ; David Airlie ; Daniel Vetter
> ; Karsten Keil ; Jassi Brar
> ; Tom Lendacky
> -Original Message-
> From: Petr Mladek
> Sent: Saturday, 13 April 2019 12:04 AM
> To: Alastair D'Silva
> Cc: alast...@d-silva.org; Jani Nikula ;
Joonas
> Lahtinen ; Rodrigo Vivi
> ; David Airlie ; Daniel Vetter
> ; Karsten Keil ; Jassi Brar
> ; Tom Lendacky
> -Original Message-
> From: David Laight
> Sent: Wednesday, 10 April 2019 6:45 PM
> To: 'Alastair D'Silva' ; alast...@d-silva.org
> Cc: Jani Nikula ; Joonas Lahtinen
> ; Rodrigo Vivi ;
> David Airlie ; Daniel Vetter ; Karsten Keil
> ; Jassi Brar ; Tom Lend
From: Alastair D'Silva
Apologies for the large CC list, it's a heads up for those responsible
for subsystems where a prototype change in generic code causes a change
in those subsystems.
This series enhances hexdump.
These improve the readability of the dumped data in certain situations
(eg
From: Alastair D'Silva
Some buffers may only be partially filled with useful data, while the rest
is padded (typically with 0x00 or 0xff).
This patch introduces flags which allow lines of padding bytes to be
suppressed, making the output easier to interpret: HEXDUMP_SUPPRESS_0X00
On Wed, 2019-04-10 at 13:17 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Some buffers may only be partially filled with useful data, while the
> rest
> is padded (typically with 0x00 or 0xff).
>
This patch introduces flags which allow lines of padding bytes
From: Alastair D'Silva
With modern high resolution screens, we can display more data, which makes
life a bit easier when debugging.
Allow 64 bytes to be dumped per line.
Signed-off-by: Alastair D'Silva
---
lib/hexdump.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions
From: Alastair D'Silva
In order to support additional features in hex_dump_to_buffer, replace
the ascii bool parameter with flags.
Signed-off-by: Alastair D'Silva
---
drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
drivers/isdn/hardware/mISDN/mISDNisar.c | 6
From: Alastair D'Silva
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:: 454d414e
51 matches
Mail list logo
