[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87frmdnvkl.fsf@bootlin.com>
Date: Tue, 24 Dec 2024 12:56:26 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Petr Mladek <pmladek@...e.com>, Steven Rostedt <rostedt@...dmis.org>,
Rasmus Villemoes <linux@...musvillemoes.dk>, Sergey Senozhatsky
<senozhatsky@...omium.org>, Jonathan Corbet <corbet@....net>, John
Ogness <john.ogness@...utronix.de>, Andrew Morton
<akpm@...ux-foundation.org>, Thomas Petazzoni
<thomas.petazzoni@...tlin.com>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] hexdump: Allow skipping identical lines
Hi Andy,
On 27/08/2024 at 16:29:18 +03, Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:
> On Tue, Aug 27, 2024 at 11:01:47AM +0200, Miquel Raynal wrote:
>> andriy.shevchenko@...ux.intel.com wrote on Mon, 26 Aug 2024 20:32:20
>> +0300:
>> > On Mon, Aug 26, 2024 at 06:24:14PM +0200, Miquel Raynal wrote:
>
> ...
>
>> > Also here is the formal NAK till the series gains the test cases.
>>
>> What test cases are you talking about?
>
> Anything meaningful you come up with to show that the printed data is
> what it's expected. The module has a complimentary test case,
> lib/test_hexdump.c. Without changes in that file, there is no go
> to what ever golden ideas you have.
I had a look. The tests never test the content of the kernel buffer,
while this is the only part that my changes have an impact on. These
tests verify the hex_dump_to_buffer() logic, but never how it is used
through the print_hex_dump_*() helpers.
In this series I am just enabling a new way to print the content of the
buffer, like for instance enabling a prefix, which is not directly
related to the core implementation of hexdump.
Hence, I am sorry, but I will disregard this request unless someone
comes up with a working idea which is worth the effort, considering the
minimum impact of this change and the fact that it is mostly (if not
only) for debugging purposes and will most likely never reach users.
Thanks,
Miquèl
Powered by blists - more mailing lists