[PATCH] obsolete config in kernel source (BUFFER_DEBUG)

[PATCH] obsolete config in kernel source (BUFFER_DEBUG)

[Christoph Egger]

Hi all!

	As part of the VAMOS[0] research project at the University of
Erlangen we're checking referential integrity between kernel KConfig
options and in-code Conditional blocks.

	With some commit somewhere around 2.4.15 the last hint of
CONFIG_BUFFER_DEBUG (apart from the 2 occurences this patch addresses)
-- some documentation -- was removed from the kernel source. However
this one piece of code made it till today. Time to go forward and
remove it?

	Please keep me informed of this patch getting confirmed /
merged so we can keep track of it.

Regards

	Christoph Egger

[0] http://vamos1.informatik.uni-erlangen.de/

----
>From cb255f19dc90e027c2f903e24c16d1f179bac67e Mon Sep 17 00:00:00 2001
From: Christoph Egger <siccegge@stud.informatik.uni-erlangen.de>
Date: Fri, 5 Feb 2010 13:08:06 +0100
Subject: [PATCH] remove references to BUFFER_DEBUG

CONFIG_BUFFER_DEBUG seems to have been removed from the documentation
somewhere around 2.4.15 and seemingly hasn't been available even
longer. It is, however, still referenced at one place from the jbd
code (one is a copy of the other header). Time to clean it up

Signed-off-by: Christoph Egger <siccegge@stud.informatik.uni-erlangen.de>
---
 include/linux/jbd.h  |   11 -----------
 include/linux/jbd2.h |   11 -----------
 2 files changed, 0 insertions(+), 22 deletions(-)

diff --git a/include/linux/jbd.h b/include/linux/jbd.h
index 331530c..f3aa59c 100644
--- a/include/linux/jbd.h
+++ b/include/linux/jbd.h
@@ -246,19 +246,8 @@ typedef struct journal_superblock_s
 
 #define J_ASSERT(assert)	BUG_ON(!(assert))
 
-#if defined(CONFIG_BUFFER_DEBUG)
-void buffer_assertion_failure(struct buffer_head *bh);
-#define J_ASSERT_BH(bh, expr)						\
-	do {								\
-		if (!(expr))						\
-			buffer_assertion_failure(bh);			\
-		J_ASSERT(expr);						\
-	} while (0)
-#define J_ASSERT_JH(jh, expr)	J_ASSERT_BH(jh2bh(jh), expr)
-#else
 #define J_ASSERT_BH(bh, expr)	J_ASSERT(expr)
 #define J_ASSERT_JH(jh, expr)	J_ASSERT(expr)
-#endif
 
 #if defined(JBD_PARANOID_IOFAIL)
 #define J_EXPECT(expr, why...)		J_ASSERT(expr)
diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
index 638ce45..4cf6191 100644
--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -284,19 +284,8 @@ typedef struct journal_superblock_s
 
 #define J_ASSERT(assert)	BUG_ON(!(assert))
 
-#if defined(CONFIG_BUFFER_DEBUG)
-void buffer_assertion_failure(struct buffer_head *bh);
-#define J_ASSERT_BH(bh, expr)						\
-	do {								\
-		if (!(expr))						\
-			buffer_assertion_failure(bh);			\
-		J_ASSERT(expr);						\
-	} while (0)
-#define J_ASSERT_JH(jh, expr)	J_ASSERT_BH(jh2bh(jh), expr)
-#else
 #define J_ASSERT_BH(bh, expr)	J_ASSERT(expr)
 #define J_ASSERT_JH(jh, expr)	J_ASSERT(expr)
-#endif
 
 #if defined(JBD2_PARANOID_IOFAIL)
 #define J_EXPECT(expr, why...)		J_ASSERT(expr)
-- 
1.6.3.3

Re: [PATCH] obsolete config in kernel source (BUFFER_DEBUG)

[Jan Kara]

On Fri 05-02-10 14:13:33, Christoph Egger wrote:
> Hi all!
> 
> 	As part of the VAMOS[0] research project at the University of
> Erlangen we're checking referential integrity between kernel KConfig
> options and in-code Conditional blocks.
> 
> 	With some commit somewhere around 2.4.15 the last hint of
> CONFIG_BUFFER_DEBUG (apart from the 2 occurences this patch addresses)
> -- some documentation -- was removed from the kernel source. However
> this one piece of code made it till today. Time to go forward and
> remove it?
> 
> 	Please keep me informed of this patch getting confirmed /
> merged so we can keep track of it.
  Thanks, the patch looks good. I've merged it into my linux-fs tree and
will send it to Linus in the next merge window.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: [PATCH] obsolete config in kernel source (BUFFER_DEBUG)

[tytso]

On Mon, Feb 08, 2010 at 02:56:29PM +0100, Jan Kara wrote:
> On Fri 05-02-10 14:13:33, Christoph Egger wrote:
> > Hi all!
> > 
> > 	As part of the VAMOS[0] research project at the University of
> > Erlangen we're checking referential integrity between kernel KConfig
> > options and in-code Conditional blocks.
> > 
> > 	With some commit somewhere around 2.4.15 the last hint of
> > CONFIG_BUFFER_DEBUG (apart from the 2 occurences this patch addresses)
> > -- some documentation -- was removed from the kernel source. However
> > this one piece of code made it till today. Time to go forward and
> > remove it?
> > 
> > 	Please keep me informed of this patch getting confirmed /
> > merged so we can keep track of it.
>   Thanks, the patch looks good. I've merged it into my linux-fs tree and
> will send it to Linus in the next merge window.

I don't have an objection with removing this, but does anyone have the
latest version of akpm's buffer debugging patches?

I *think* what happened is that akpm forward ported the removed buffer
debugging patches, or maybe rewrote it from scratch, but for whatever
reason they never made back into mainline.  Maybe they were too ugly
to live in mainline, but they have been really handy on occasion.

   	   	     	      	   	       - Ted

Re: [PATCH] obsolete config in kernel source (BUFFER_DEBUG)

[Andrew Morton]

On Mon, 8 Feb 2010 10:50:31 -0500 tytso@mit.edu wrote:

> I don't have an objection with removing this, but does anyone have the
> latest version of akpm's buffer debugging patches?

My version is datestamped four years ago :( It normally forward-ports
fairly easily.

> I *think* what happened is that akpm forward ported the removed buffer
> debugging patches, or maybe rewrote it from scratch, but for whatever
> reason they never made back into mainline.  Maybe they were too ugly
> to live in mainline, but they have been really handy on occasion.

I think Eric Sandeen might have a fresher version.  Nowadays it should
be done with the tracing infrastructure, I guess.  Although that
infrastructure may not be able to do this - the ext3 debug patch
recorded an LRU array of the below structs within every buffer_head. 
The various BUFFER_TRACE macros would emit a new record into the tail of the
target bh's b[] ring.

struct buffer_history {
	struct buffer_history_item {
		char *function;
		char *info;
		unsigned long b_state;
		unsigned b_list:3;
		unsigned b_jlist:4;
		unsigned pg_dirty:1;
		unsigned cpu:3;
		unsigned b_count:8;
		unsigned long b_blocknr;	/* For src != dest */
#if defined(CONFIG_JBD) || defined(CONFIG_JBD_MODULE)
		unsigned b_jcount:4;
		unsigned b_jbd:1;
		unsigned b_transaction:1;
		unsigned b_next_transaction:1;
		unsigned b_cp_transaction:1;
		unsigned b_trans_is_running:1;
		unsigned b_trans_is_committing:1;
		void *b_frozen_data;
		void *b_committed_data;
#endif
	} b[BUFFER_HISTORY_SIZE];
	unsigned long b_history_head;	/* Next place to write */
	unsigned long b_history_tail;	/* Oldest valid entry */
};

Re: [PATCH] obsolete config in kernel source (BUFFER_DEBUG)

[Eric Sandeen]

Andrew Morton wrote:
> On Mon, 8 Feb 2010 10:50:31 -0500 tytso@mit.edu wrote:
> 
>> I don't have an objection with removing this, but does anyone have the
>> latest version of akpm's buffer debugging patches?
> 
> My version is datestamped four years ago :( It normally forward-ports
> fairly easily.
> 
>> I *think* what happened is that akpm forward ported the removed buffer
>> debugging patches, or maybe rewrote it from scratch, but for whatever
>> reason they never made back into mainline.  Maybe they were too ugly
>> to live in mainline, but they have been really handy on occasion.
> 
> I think Eric Sandeen might have a fresher version. 

If "fresh" means 2.6.18, I might ;)

But yes they sure have come in handy from time to time.

> Nowadays it should
> be done with the tracing infrastructure, I guess.

that's kind of what I was thinking, too.

-Eric

>  Although that
> infrastructure may not be able to do this - the ext3 debug patch
> recorded an LRU array of the below structs within every buffer_head. 
> The various BUFFER_TRACE macros would emit a new record into the tail of the
> target bh's b[] ring.
> 
> struct buffer_history {
> 	struct buffer_history_item {
> 		char *function;
> 		char *info;
> 		unsigned long b_state;
> 		unsigned b_list:3;
> 		unsigned b_jlist:4;
> 		unsigned pg_dirty:1;
> 		unsigned cpu:3;
> 		unsigned b_count:8;
> 		unsigned long b_blocknr;	/* For src != dest */
> #if defined(CONFIG_JBD) || defined(CONFIG_JBD_MODULE)
> 		unsigned b_jcount:4;
> 		unsigned b_jbd:1;
> 		unsigned b_transaction:1;
> 		unsigned b_next_transaction:1;
> 		unsigned b_cp_transaction:1;
> 		unsigned b_trans_is_running:1;
> 		unsigned b_trans_is_committing:1;
> 		void *b_frozen_data;
> 		void *b_committed_data;
> #endif
> 	} b[BUFFER_HISTORY_SIZE];
> 	unsigned long b_history_head;	/* Next place to write */
> 	unsigned long b_history_tail;	/* Oldest valid entry */
> };
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] obsolete config in kernel source (BUFFER_DEBUG)

[Christoph Egger]

Hi all!

	As part of the VAMOS[0] research project at the University of
Erlangen we're checking referential integrity between kernel KConfig
options and in-code Conditional blocks.

	This is another example of a block of code, here since ever
and never compiled in modern history. Couldn't find out much more
about it but as it can't be set for ages it might be wise to just
remove it right now?

	Please keep me informed of this patch getting confirmed /
merged so we can keep track of it.

Regards

	Christoph Egger

[0] http://vamos1.informatik.uni-erlangen.de/

----
>From 5cb8acd3f6939c617d6f28bd3eabb276c443c34e Mon Sep 17 00:00:00 2001
From: Christoph Egger <siccegge@stud.informatik.uni-erlangen.de>
Date: Fri, 5 Feb 2010 13:39:33 +0100
Subject: [PATCH] Remove config SCSI_DC395x_TRMS1040_TRADMAP

There's exactly one in source-check for SCSI_DC395x_TRMS1040_TRADMAP
imported with the first git revision and no corresponding KConfig Item
ever. Removing this single left-over block from the kernel config.

Signed-off-by: Christoph Egger <siccegge@stud.informatik.uni-erlangen.de>
---
 drivers/scsi/dc395x.c |   22 ----------------------
 1 files changed, 0 insertions(+), 22 deletions(-)

diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c
index 6c59c02..7b3d0d3 100644
--- a/drivers/scsi/dc395x.c
+++ b/drivers/scsi/dc395x.c
@@ -1160,29 +1160,7 @@ complete:
 static int dc395x_bios_param(struct scsi_device *sdev,
 		struct block_device *bdev, sector_t capacity, int *info)
 {
-#ifdef CONFIG_SCSI_DC395x_TRMS1040_TRADMAP
-	int heads, sectors, cylinders;
-	struct AdapterCtlBlk *acb;
-	int size = capacity;
-
-	dprintkdbg(DBG_0, "dc395x_bios_param..............\n");
-	acb = (struct AdapterCtlBlk *)sdev->host->hostdata;
-	heads = 64;
-	sectors = 32;
-	cylinders = size / (heads * sectors);
-
-	if ((acb->gmode2 & NAC_GREATER_1G) && (cylinders > 1024)) {
-		heads = 255;
-		sectors = 63;
-		cylinders = size / (heads * sectors);
-	}
-	geom[0] = heads;
-	geom[1] = sectors;
-	geom[2] = cylinders;
-	return 0;
-#else
 	return scsicam_bios_param(bdev, capacity, info);
-#endif
 }
 
 
-- 
1.6.3.3

Re: [PATCH] obsolete config in kernel source (BUFFER_DEBUG)

[James Bottomley]

On Fri, 2010-02-05 at 14:35 +0100, Christoph Egger wrote:
> 	As part of the VAMOS[0] research project at the University of
> Erlangen we're checking referential integrity between kernel KConfig
> options and in-code Conditional blocks.
> 
> 	This is another example of a block of code, here since ever
> and never compiled in modern history. Couldn't find out much more
> about it but as it can't be set for ages it might be wise to just
> remove it right now?

To be honest, not really unless the person maintaining the driver
agrees.  The reason for not doing this to obsolete drivers is that
although in theory git will remember it, trying to find a lost block of
code in git is time consuming and you often have to know where to look
for it.  Secondly, the code might be relevant to someone actually
needing to fix or use the driver.  Sometimes the code in non compiled
blocks can give valuable insights into how the driver actually worked.

Often, for dead code we don't quite know what to do with, we surround it
with #if 0/#endif blocks to make it quite clear it's not compiled, but
for nonexistent config options, that's not really necessary.

> 	Please keep me informed of this patch getting confirmed /
> merged so we can keep track of it.
> 
> Regards
> 
> 	Christoph Egger
> 
> [0] http://vamos1.informatik.uni-erlangen.de/
> 
> ----
> From 5cb8acd3f6939c617d6f28bd3eabb276c443c34e Mon Sep 17 00:00:00 2001
> From: Christoph Egger <siccegge@stud.informatik.uni-erlangen.de>
> Date: Fri, 5 Feb 2010 13:39:33 +0100
> Subject: [PATCH] Remove config SCSI_DC395x_TRMS1040_TRADMAP
> 
> There's exactly one in source-check for SCSI_DC395x_TRMS1040_TRADMAP
> imported with the first git revision and no corresponding KConfig Item
> ever. Removing this single left-over block from the kernel config.
> 
> Signed-off-by: Christoph Egger <siccegge@stud.informatik.uni-erlangen.de>
> ---
>  drivers/scsi/dc395x.c |   22 ----------------------
>  1 files changed, 0 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c
> index 6c59c02..7b3d0d3 100644
> --- a/drivers/scsi/dc395x.c
> +++ b/drivers/scsi/dc395x.c
> @@ -1160,29 +1160,7 @@ complete:
>  static int dc395x_bios_param(struct scsi_device *sdev,
>  		struct block_device *bdev, sector_t capacity, int *info)
>  {
> -#ifdef CONFIG_SCSI_DC395x_TRMS1040_TRADMAP
> -	int heads, sectors, cylinders;
> -	struct AdapterCtlBlk *acb;
> -	int size = capacity;
> -
> -	dprintkdbg(DBG_0, "dc395x_bios_param..............\n");
> -	acb = (struct AdapterCtlBlk *)sdev->host->hostdata;
> -	heads = 64;
> -	sectors = 32;
> -	cylinders = size / (heads * sectors);
> -
> -	if ((acb->gmode2 & NAC_GREATER_1G) && (cylinders > 1024)) {
> -		heads = 255;
> -		sectors = 63;
> -		cylinders = size / (heads * sectors);
> -	}
> -	geom[0] = heads;
> -	geom[1] = sectors;
> -	geom[2] = cylinders;
> -	return 0;

So this looks like a standard bios remapping for something ... I'd guess
a traditional mapping flag for the TekRam 1040.  Someone would likely
have to dig into history to find out what it was originally for and why
it's still here.

James