re-add zft_dirty to zftape-ctl.c
PATCH 1/1 re-add zft_dirty to zftape-ctl.c
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
drivers/char/ftape/zftape/zftape-ctl.c +44 -0
@@ -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
Quoted 10 lines · Adrian Bunk
Hi Alan,
your
[PATCH] rescue ftape from the ravages of that Rusty chap
removed
zft_dirtyfromzftape-ctl.cin Linus' 2.5 tree. This seems to be accidentially and wrong, it was the only definition ofzft_dirtyin 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
Quoted 7 lines · Alan Cox
Quoted 6 lines · Adrian Bunk
Hi Alan,
your
[PATCH] rescue ftape from the ravages of that Rusty chap
Quoted 8 lines
Quoted 4 lines
removed
zft_dirtyfromzftape-ctl.cin Linus' 2.5 tree. This seems to be accidentially and wrong, it was the only definition ofzft_dirtyin 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_dirtyfunction 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?
Quoted 1 line
Alan
cu
Adrian
drivers/char/ftape/zftape/zftape-ctl.h renamed from drivers/char/ftape/zftape/zftape-ctl.h.old +0 -1
@@ -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 */
drivers/char/ftape/zftape/zftape-ctl.c renamed from drivers/char/ftape/zftape/zftape-ctl.c.old +0 -7
@@ -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 */ }
Quoted 1 line · Adrian Bunk
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