From: Adrian Bunk <bunk@fs.tum.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org, claus@momo.math.rwth-aachen.de,
linux-tape@vger.kernel.org,
Linus Torvalds <torvalds@transmeta.com>
Subject: [2.5 patch] re-add zft_dirty to zftape-ctl.c
Date: Sat, 4 Jan 2003 16:14:05 +0100 [thread overview]
Message-ID: <20030104151404.GX6114@fs.tum.de> (raw)
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
next reply other threads:[~2003-01-04 15:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-04 15:14 Adrian Bunk [this message]
2003-01-04 20:28 ` [2.5 patch] re-add zft_dirty to zftape-ctl.c Alan Cox
2003-01-06 13:31 ` Adrian Bunk
2003-01-06 14:50 ` Alan Cox
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=20030104151404.GX6114@fs.tum.de \
--to=bunk@fs.tum.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=claus@momo.math.rwth-aachen.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tape@vger.kernel.org \
--cc=torvalds@transmeta.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.