* [2.5 patch] re-add zft_dirty to zftape-ctl.c
@ 2003-01-04 15:14 Adrian Bunk
2003-01-04 20:28 ` Alan Cox
0 siblings, 1 reply; 4+ messages in thread
From: Adrian Bunk @ 2003-01-04 15:14 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, claus, linux-tape, Linus Torvalds
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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [2.5 patch] re-add zft_dirty to zftape-ctl.c
2003-01-04 15:14 [2.5 patch] re-add zft_dirty to zftape-ctl.c Adrian Bunk
@ 2003-01-04 20:28 ` Alan Cox
2003-01-06 13:31 ` Adrian Bunk
0 siblings, 1 reply; 4+ messages in thread
From: Alan Cox @ 2003-01-04 20:28 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Linux Kernel Mailing List, claus, linux-tape, Linus Torvalds
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [2.5 patch] re-add zft_dirty to zftape-ctl.c
2003-01-04 20:28 ` Alan Cox
@ 2003-01-06 13:31 ` Adrian Bunk
2003-01-06 14:50 ` Alan Cox
0 siblings, 1 reply; 4+ messages in thread
From: Adrian Bunk @ 2003-01-06 13:31 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List, claus, linux-tape, Linus Torvalds
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 */
}
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-01-06 13:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-04 15:14 [2.5 patch] re-add zft_dirty to zftape-ctl.c Adrian Bunk
2003-01-04 20:28 ` Alan Cox
2003-01-06 13:31 ` Adrian Bunk
2003-01-06 14:50 ` Alan Cox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox