All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Sachin P Sant <sachinp@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	linux-mtd@lists.infradead.org,
	Adrian Hunter <adrian.hunter@nokia.com>,
	Subrata Modak <subrata@linux.vnet.ibm.com>,
	Balbir Singh <balbir@linux.vnet.ibm.com>
Subject: Re: [PATCH 02/06] Fix compilation warning for fs/ubifs/commit.c
Date: Thu, 16 Jul 2009 15:11:30 +0300	[thread overview]
Message-ID: <1247746290.11353.146.camel@localhost.localdomain> (raw)
In-Reply-To: <4A5F15B0.9030100@s5r6.in-berlin.de>

On Thu, 2009-07-16 at 13:57 +0200, Stefan Richter wrote:
> Stefan Richter wrote:
> > So, is uninitialized_var() a good fix here?  I'd say it's not a 
> > particular good one.  Count the lines of code of dbg_check_old_index() 
> > and the maximum indentation level of it.  Then remember the teachings of 
> > CodingStyle. :-)  See?  dbg_check_old_index() clearly isn't a prime 
> > example of best kernel coding practice.  /Perhaps/ a little bit of 
> > refactoring would make it easier to read, and as a bonus side effect, 
> > make it unnecessary to use the slightly dangerous and 
> > uninitialized_var() macro here.
> 
> PS:
> On the other hand, it is debug code.  Is it bound to stay in there 
> forever?  If not, then it's surely not worth the developer time to 
> beautify it.

Yes, it is debugging code. It is doing additional consistency/sanity
checks of the internal data structures when you compile it in and enable
it. And yes, I'd like it to stay there forever, because it is a very
nice tool to catch bugs. In fact, I am really keen of this type of
debugging when you have internal checking functions. They help a lot.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind@infradead.org>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Subrata Modak <subrata@linux.vnet.ibm.com>,
	linux-mtd@lists.infradead.org,
	Adrian Hunter <adrian.hunter@nokia.com>,
	Sachin P Sant <sachinp@linux.vnet.ibm.com>,
	David Howells <dhowells@redhat.com>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 02/06] Fix compilation warning for fs/ubifs/commit.c
Date: Thu, 16 Jul 2009 15:11:30 +0300	[thread overview]
Message-ID: <1247746290.11353.146.camel@localhost.localdomain> (raw)
In-Reply-To: <4A5F15B0.9030100@s5r6.in-berlin.de>

On Thu, 2009-07-16 at 13:57 +0200, Stefan Richter wrote:
> Stefan Richter wrote:
> > So, is uninitialized_var() a good fix here?  I'd say it's not a 
> > particular good one.  Count the lines of code of dbg_check_old_index() 
> > and the maximum indentation level of it.  Then remember the teachings of 
> > CodingStyle. :-)  See?  dbg_check_old_index() clearly isn't a prime 
> > example of best kernel coding practice.  /Perhaps/ a little bit of 
> > refactoring would make it easier to read, and as a bonus side effect, 
> > make it unnecessary to use the slightly dangerous and 
> > uninitialized_var() macro here.
> 
> PS:
> On the other hand, it is debug code.  Is it bound to stay in there 
> forever?  If not, then it's surely not worth the developer time to 
> beautify it.

Yes, it is debugging code. It is doing additional consistency/sanity
checks of the internal data structures when you compile it in and enable
it. And yes, I'd like it to stay there forever, because it is a very
nice tool to catch bugs. In fact, I am really keen of this type of
debugging when you have internal checking functions. They help a lot.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)


  reply	other threads:[~2009-07-16 12:11 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-15  2:19 [PATCH 02/06] Fix compilation warning for fs/ubifs/commit.c Subrata Modak
2009-07-15  2:19 ` Subrata Modak
2009-07-15  6:52 ` Artem Bityutskiy
2009-07-15  6:52   ` Artem Bityutskiy
2009-07-15 18:16   ` Stefan Richter
2009-07-15 18:16     ` Stefan Richter
2009-07-16  9:57     ` Artem Bityutskiy
2009-07-16  9:57       ` Artem Bityutskiy
2009-07-16 11:04       ` Subrata Modak
2009-07-16 11:04         ` Subrata Modak
2009-07-16 11:12         ` Artem Bityutskiy
2009-07-16 11:12           ` Artem Bityutskiy
2009-07-16 11:21           ` Subrata Modak
2009-07-16 11:21             ` Subrata Modak
2009-07-16 11:46         ` Stefan Richter
2009-07-16 11:46           ` Stefan Richter
2009-07-16 11:29       ` Stefan Richter
2009-07-16 11:29         ` Stefan Richter
2009-07-16 11:57         ` Stefan Richter
2009-07-16 11:57           ` Stefan Richter
2009-07-16 12:11           ` Artem Bityutskiy [this message]
2009-07-16 12:11             ` Artem Bityutskiy
2009-07-16 12:09         ` Artem Bityutskiy
2009-07-16 12:09           ` Artem Bityutskiy
  -- strict thread matches above, loose matches on Subject: below --
2009-07-16 12:41 Subrata Modak
2009-07-16 12:41 ` Subrata Modak
2009-07-16 12:54 ` Artem Bityutskiy
2009-07-16 12:54   ` Artem Bityutskiy
2009-07-16 13:10   ` Subrata Modak
2009-07-16 13:10     ` Subrata Modak

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=1247746290.11353.146.camel@localhost.localdomain \
    --to=dedekind@infradead.org \
    --cc=adrian.hunter@nokia.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=sachinp@linux.vnet.ibm.com \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=subrata@linux.vnet.ibm.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.