[2.5 patch] re-add zft_dirty to zftape-ctl.c

[2.5 patch] re-add zft_dirty to zftape-ctl.c

[Adrian Bunk]

Hi Alan,

your

  [PATCH] rescue ftape from the ravages of that Rusty chap

removed zft_dirty from zftape-ctl.c in Linus' 2.5 tree. This seems to be
accidentially and wrong, it was the only definition of zft_dirty in the
whole kernel sources and now there's an error at the final linking of
the kernel. The patch below (against 2.5.54) re-adds it.

cu
Adrian

--- linux/drivers/char/ftape/zftape/zftape-ctl.c	2003-01-02 04:21:44.000000000 +0100
+++ linux/drivers/char/ftape/zftape/zftape-ctl.c	2000-10-16 21:58:51.000000000 +0200
@@ -648,6 +648,50 @@
 	TRACE_EXIT 0;
 }
 
+/*  decide when we should lock the module in memory, even when calling
+ *  the release routine. This really is necessary for use with
+ *  kerneld.
+ *
+ *  NOTE: we MUST NOT use zft_write_protected, because this includes
+ *  the file access mode as well which has no meaning with our 
+ *  asynchronous update scheme.
+ *
+ *  Ugly, ugly. We need to look the module if we changed the block size.
+ *  How sad! Need persistent modules storage!
+ *
+ *  NOTE: I don't want to lock the module if the number of dma buffers 
+ *  has been changed. It's enough! Stop the story! Give me persisitent
+ *  module storage! Do it!
+ */
+int zft_dirty(void)
+{
+	if (!ft_formatted || zft_offline) { 
+		/* cannot be dirty if not formatted or offline */
+		return 0;
+	}
+	if (zft_blk_sz != CONFIG_ZFT_DFLT_BLK_SZ) {
+		/* blocksize changed, must lock */
+		return 1;
+	}
+	if (zft_mt_compression != 0) {
+		/* compression mode with /dev/qft, must lock */
+		return 1;
+	}
+	if (!zft_header_read) {
+		/* tape is logical at BOT, no lock */
+		return 0;
+	}
+	if (!zft_tape_at_lbot(&zft_pos)) {
+		/* somewhere inside a volume, lock tape */
+		return 1;
+	}
+	if (zft_volume_table_changed || zft_header_changed) {
+		/* header segments dirty if tape not write protected */
+		return !(ft_write_protected || zft_old_ftape);
+	}
+	return 0;
+}
+
 /*      OPEN routine called by kernel-interface code
  *
  *      NOTE: this is also called by mt_reset() with dev_minor == -1

Re: [2.5 patch] re-add zft_dirty to zftape-ctl.c

[Alan Cox]

On Sat, 2003-01-04 at 15:14, Adrian Bunk wrote:
> Hi Alan,
> 
> your
> 
>   [PATCH] rescue ftape from the ravages of that Rusty chap
> 
> removed zft_dirty from zftape-ctl.c in Linus' 2.5 tree. This seems to be
> accidentially and wrong, it was the only definition of zft_dirty in the
> whole kernel sources and now there's an error at the final linking of
> the kernel. The patch below (against 2.5.54) re-adds it.

I disagree entirely. The zft_dirty function is junk. I accidentally missed
removing one other reference to it when you compile it in, that is all. For some
reason the fix to that never got into Linus tree. Remove the other use of it.


Alan

Re: [2.5 patch] re-add zft_dirty to zftape-ctl.c

[Adrian Bunk]

On Sat, Jan 04, 2003 at 08:28:48PM +0000, Alan Cox wrote:
> On Sat, 2003-01-04 at 15:14, Adrian Bunk wrote:
> > Hi Alan,
> > 
> > your
> > 
> >   [PATCH] rescue ftape from the ravages of that Rusty chap
> > 
> > removed zft_dirty from zftape-ctl.c in Linus' 2.5 tree. This seems to be
> > accidentially and wrong, it was the only definition of zft_dirty in the
> > whole kernel sources and now there's an error at the final linking of
> > the kernel. The patch below (against 2.5.54) re-adds it.
> 
> I disagree entirely. The zft_dirty function is junk. I accidentally missed
> removing one other reference to it when you compile it in, that is all. For some
> reason the fix to that never got into Linus tree. Remove the other use of it.

Is the patch below correct?

> Alan

cu
Adrian

--- linux-2.5.54/drivers/char/ftape/zftape/zftape-ctl.h.old	2003-01-06 14:23:51.000000000 +0100
+++ linux-2.5.54/drivers/char/ftape/zftape/zftape-ctl.h	2003-01-06 14:24:02.000000000 +0100
@@ -47,7 +47,6 @@
 extern void zft_reset_position(zft_position *pos);
 extern int  zft_check_write_access(zft_position *pos);
 extern int  zft_def_idle_state(void);
-extern int  zft_dirty(void);
 
 /*  hooks for the VFS interface 
  */
--- linux-2.5.54/drivers/char/ftape/zftape/zftape-ctl.c.old	2003-01-06 14:22:49.000000000 +0100
+++ linux-2.5.54/drivers/char/ftape/zftape/zftape-ctl.c	2003-01-06 14:23:43.000000000 +0100
@@ -790,13 +790,6 @@
 		zft_uninit_mem();
 		going_offline = 0;
 		zft_offline   = 1;
-	} else if (zft_dirty()) {
-		TRACE(ft_t_noise, "Keeping module locked in memory because:\n"
-		      KERN_INFO "header segments need updating: %s\n"
-		      KERN_INFO "tape not at BOT              : %s",
-		      (zft_volume_table_changed || zft_header_changed) 
-		      ? "yes" : "no",
-		      zft_tape_at_lbot(&zft_pos) ? "no" : "yes");
 	} else if (zft_cmpr_lock(0 /* don't load */) == 0) {
 		(*zft_cmpr_ops->reset)(); /* unlock it again */
 	}

Re: [2.5 patch] re-add zft_dirty to zftape-ctl.c

[Alan Cox]

On Mon, 2003-01-06 at 13:31, Adrian Bunk wrote:
> Is the patch below correct?

I think so yes. The module is locked until close by refcount and the close seems to flush the
tape headers