Re: Di-30 non working [bug 967]

From: Stef van der Made
Date: Sun Nov 02 2003 - 14:44:48 EST



Dear Bartlomiej,

The problem is now fully solved. I can read from the tape, use mt on the tape drive. Your second patch was the final missing bit.

Thanks for your help, I hope that Linus will accept the patch for test10 so that more people can enjoy the use of this tape drive with Linux.

Stef

Bartlomiej Zolnierkiewicz wrote:

On Sunday 02 of November 2003 00:24, Andrew Morton wrote:


Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@xxxxxxxxxxxxxx> wrote:


Noticed by Stuart_Hayes@xxxxxxxx:

I've noticed that, in the 2.6 (test 9) kernel, the "cmd" field (of type
int) in struct request has been removed, and it looks like all of the
code in ide-tape has just had a find & replace run on it to replace any
instance of rq.cmd or rq->cmd with rq.flags or rq->flags.


Nasty.



@@ -193,6 +193,11 @@ enum rq_flag_bits {
__REQ_PM_SUSPEND, /* suspend request */
__REQ_PM_RESUME, /* resume request */
__REQ_PM_SHUTDOWN, /* shutdown request */
+ __REQ_IDETAPE_PC1, /* packet command (first stage) */
+ __REQ_IDETAPE_PC2, /* packet command (second stage) */
+ __REQ_IDETAPE_READ,
+ __REQ_IDETAPE_WRITE,
+ __REQ_IDETAPE_READ_BUFFER,
__REQ_NR_BITS, /* stops here */
};


This takes us up to about 28 flags; we'll run out soon.

Probably it is time to split this into generic and private flags, as we did
with bh_state_bits. The scope of the "private" section needs to be
defined: maybe "whoever created the queue"?



This issue was already discussed and is planned for 2.7. :-)



blk_dump_rq_flags() will need updating. Probably change it to only decode
the "generic" flags, and print "bit XX" for the remainders.

Your patch forgot to update rq_flags[] btw.



Thanks, fixed.

I overlooked fact that ide-tape is calling ide_init_drive_cmd() just to zero
rq and then overwrites rq->flags, fixed. Stef, please try corrected patch.





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/