All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
To: <dedekind1@gmail.com>
Cc: Joe Perches <joe@perches.com>,
	dwmw2@infradead.org, linux-mtd@lists.infradead.org,
	linux-kernel@vger.kernel.org, nicolas.ferre@atmel.com
Subject: Re: [PATCH 2/2] jffs2: fix buffer dump debug output
Date: Tue, 21 Oct 2014 12:17:26 +0200	[thread overview]
Message-ID: <544632B6.60701@atmel.com> (raw)
In-Reply-To: <1413885267.7906.426.camel@sauron.fi.intel.com>

Le 21/10/2014 11:54, Artem Bityutskiy a écrit :
> On Tue, 2014-10-21 at 11:47 +0200, Cyrille Pitchen wrote:
>> thanks for your comment. Indeed using print_hex_dump() would be a good idea
>> since it would avoid each driver to implement its own version of buffer dumps.
>> Reading the source code of print_hex_dump(), the output format would change a
>> little bit:
>> the output would no longer be aligned to JFFS2_BUFDUMP_BYTES_PER_LINE boundary
>> using leading spaces.
>> If it's ok to change the output format it's good for me as well.
> 
> Changing format is OK, this is just a debugging cruft. But it is OK only
> if you test the changes. If you are unable to test the changes, it is
> better to avoid doing non-trivial changes.
> 
The version provided in this patch was tested. However I don't know how to cope
with the offs parameter of __jffs2_dbg_dump_buffer() if I replace the current
source code by a call to print_hex_dump().
If I use DUMP_PREFIX_ADDRESS as prefix_type value, the printed offsets are
relative to the address of buf in RAM, not to the hardware offset in my
dataflash provided by the offs parameter.
Also, if I use DUMP_PREFIX_OFFSET, the printed offsets start from 0 instead of
offs value.

I think keeping the right offsets in the output dump is helpfull.

WARNING: multiple messages have this Message-ID (diff)
From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
To: <dedekind1@gmail.com>
Cc: Joe Perches <joe@perches.com>, <linux-mtd@lists.infradead.org>,
	<dwmw2@infradead.org>, <linux-kernel@vger.kernel.org>,
	<nicolas.ferre@atmel.com>
Subject: Re: [PATCH 2/2] jffs2: fix buffer dump debug output
Date: Tue, 21 Oct 2014 12:17:26 +0200	[thread overview]
Message-ID: <544632B6.60701@atmel.com> (raw)
In-Reply-To: <1413885267.7906.426.camel@sauron.fi.intel.com>

Le 21/10/2014 11:54, Artem Bityutskiy a écrit :
> On Tue, 2014-10-21 at 11:47 +0200, Cyrille Pitchen wrote:
>> thanks for your comment. Indeed using print_hex_dump() would be a good idea
>> since it would avoid each driver to implement its own version of buffer dumps.
>> Reading the source code of print_hex_dump(), the output format would change a
>> little bit:
>> the output would no longer be aligned to JFFS2_BUFDUMP_BYTES_PER_LINE boundary
>> using leading spaces.
>> If it's ok to change the output format it's good for me as well.
> 
> Changing format is OK, this is just a debugging cruft. But it is OK only
> if you test the changes. If you are unable to test the changes, it is
> better to avoid doing non-trivial changes.
> 
The version provided in this patch was tested. However I don't know how to cope
with the offs parameter of __jffs2_dbg_dump_buffer() if I replace the current
source code by a call to print_hex_dump().
If I use DUMP_PREFIX_ADDRESS as prefix_type value, the printed offsets are
relative to the address of buf in RAM, not to the hardware offset in my
dataflash provided by the offs parameter.
Also, if I use DUMP_PREFIX_OFFSET, the printed offsets start from 0 instead of
offs value.

I think keeping the right offsets in the output dump is helpfull.

  reply	other threads:[~2014-10-21 10:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-21  8:04 [PATCH 0/2] *** jffs2: fix debug outputs *** Cyrille Pitchen
2014-10-21  8:04 ` Cyrille Pitchen
2014-10-21  8:04 ` [PATCH 1/2] jffs2: fix wrong offset in an error msg from __jff2_dbg_prewrite_paranoia_check Cyrille Pitchen
2014-10-21  8:04   ` Cyrille Pitchen
2014-10-21  8:05 ` [PATCH 2/2] jffs2: fix buffer dump debug output Cyrille Pitchen
2014-10-21  8:05   ` Cyrille Pitchen
2014-10-21  8:17   ` Joe Perches
2014-10-21  8:17     ` Joe Perches
2014-10-21  9:47     ` Cyrille Pitchen
2014-10-21  9:47       ` Cyrille Pitchen
2014-10-21  9:54       ` Artem Bityutskiy
2014-10-21  9:54         ` Artem Bityutskiy
2014-10-21 10:17         ` Cyrille Pitchen [this message]
2014-10-21 10:17           ` Cyrille Pitchen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=544632B6.60701@atmel.com \
    --to=cyrille.pitchen@atmel.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nicolas.ferre@atmel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.