Re: [PATCH Linux 2.6.12-rc5-mm2 08/09] blk: update IDE to use thenew blk_ordered.

From: Tejun Heo
Date: Mon Jun 06 2005 - 21:28:41 EST



Hello, Jeff.
Hello, Bartlomiej.

Bartlomiej Zolnierkiewicz wrote:
On 6/5/05, Jeff Garzik <jgarzik@xxxxxxxxx> wrote:

Tejun Heo wrote:

@@ -176,6 +176,18 @@ static ide_startstop_t __ide_do_rw_disk(
lba48 = 0;
}

+ if (blk_fua_rq(rq) &&
+ (!rq_data_dir(rq) || !drive->select.b.lba || !lba48)) {
+ if (!rq_data_dir(rq))
+ printk(KERN_WARNING "%s: FUA READ unsupported\n",
+ drive->name);
+ else
+ printk(KERN_WARNING "%s: FUA request received but "
+ "cannot use LBA48\n", drive->name);
+ ide_end_request(drive, 0, 0);
+ return ide_stopped;
+ }
+


Does this string of tests really need to be added to the main fast path?

It would be better to simply guarantee that this check need never exist
in the IDE driver, by guaranteeing that the block layer will never send
a FUA-READ command to a driver that does not wish it.

Jeff

I am not particulary proud of the way I've modified the IDE driver but, to defend my ass a bit, the structure of __ide_do_rw_disk() was a little bit awkward to add FUA support as it first loads all address registers and then looks what to execute, and I didn't want to load taskfile registers only to abort the command.

Currently none issues FUA READs, so the rq_data_dir() test can go away but I think it's just nice to have it there for completeness. As the whole test is invoked only when blk_fua_rq() is true, I don't think the overhead will be anything accountable (or reducible). And for the following select.b.lba and lba48 tests, we actually only need the lba48 test but I wasn't really sure whether lba48 implies select.b.lba. It seems it currently does but I couldn't find anything that guarantees it by design. Bartlomiej, is it safe to skip select.b.lba test?

I'll try to make it look better. If you have any ideas, please let me know.



Seconded, plus please use <linux/ata.h> instead of <linux/hdreg.h>
for adding new opcodes.

will do.

Thank you a lot.

--
tejun
-
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/