* [PATCH] Is it time to kill ide-scsi.c?
@ 2007-07-04 15:29 Boaz Harrosh
2007-07-05 23:50 ` Jeff Garzik
0 siblings, 1 reply; 3+ messages in thread
From: Boaz Harrosh @ 2007-07-04 15:29 UTC (permalink / raw)
To: James Bottomley, Jeff Garzik, Andrew Morton, linux-scsi,
FUJITA Tomonori
I have attempted (below) to convert ide-scsi to the new data
accessors and cleanup the !use_sg code paths. Inspecting
the code I can see places that still assume scsi_cmnd->request_buffer
is a linear char pointer. Though I admit this assumption is hidden
behind a flag "test_bit(PC_TRANSFORM, &pc->flags)". Is this an indication
that this drivers no longer works? What is needed in order to kill this
driver? If no killing is done than please accepted below patch.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
---
drivers/scsi/ide-scsi.c | 48 ++++++++++++++++++++++++++++------------------
1 files changed, 29 insertions(+), 19 deletions(-)
diff --git a/drivers/scsi/ide-scsi.c b/drivers/scsi/ide-scsi.c
index bb90df8..4ee7ef3 100644
--- a/drivers/scsi/ide-scsi.c
+++ b/drivers/scsi/ide-scsi.c
@@ -175,7 +175,8 @@ static void idescsi_input_buffers (ide_drive_t *drive, idescsi_pc_t *pc, unsigne
char *buf;
while (bcount) {
- if (pc->sg - (struct scatterlist *) pc->scsi_cmd->request_buffer > pc->scsi_cmd->use_sg) {
+ if (pc->sg - scsi_sglist(pc->scsi_cmd) >
+ scsi_sg_count(pc->scsi_cmd)) {
printk (KERN_ERR "ide-scsi: scatter gather table too small, discarding data\n");
idescsi_discard_data (drive, bcount);
return;
@@ -210,7 +211,8 @@ static void idescsi_output_buffers (ide_drive_t *drive, idescsi_pc_t *pc, unsign
char *buf;
while (bcount) {
- if (pc->sg - (struct scatterlist *) pc->scsi_cmd->request_buffer > pc->scsi_cmd->use_sg) {
+ if (pc->sg - scsi_sglist(pc->scsi_cmd) >
+ scsi_sg_count(pc->scsi_cmd)) {
printk (KERN_ERR "ide-scsi: scatter gather table too small, padding with zeros\n");
idescsi_output_zeros (drive, bcount);
return;
@@ -287,6 +289,21 @@ static inline void idescsi_transform_pc1 (ide_drive_t *drive, idescsi_pc_t *pc)
static inline void idescsi_transform_pc2 (ide_drive_t *drive, idescsi_pc_t *pc)
{
+ if (!test_bit(PC_TRANSFORM, &pc->flags))
+ return;
+
+ /*
+ * FIXME: if code reached here than this driver is not
+ * working for sure. If it is a dead code than it can
+ * surly be properly removed.
+ *
+ * Same is with above idescsi_transform_pc1() which
+ * assumes pc->buffer must have something which surly
+ * does not.
+ */
+ BUG();
+
+#if 0
u8 *atapi_buf = pc->buffer;
u8 *sc = pc->scsi_cmd->cmnd;
u8 *scsi_buf = pc->scsi_cmd->request_buffer;
@@ -308,6 +325,7 @@ static inline void idescsi_transform_pc2 (ide_drive_t *drive, idescsi_pc_t *pc)
}
if (atapi_buf && atapi_buf != scsi_buf)
kfree(atapi_buf);
+#endif
}
static void hexdump(u8 *x, int len)
@@ -437,6 +455,7 @@ static int idescsi_end_request (ide_drive_t *drive, int uptodate, int nrsecs)
} else {
pc->scsi_cmd->result = DID_OK << 16;
idescsi_transform_pc2 (drive, pc);
+#if 0
if (log) {
printk ("ide-scsi: %s: suc %lu", drive->name, pc->scsi_cmd->serial_number);
if (!test_bit(PC_WRITING, &pc->flags) && pc->actually_transferred && pc->actually_transferred <= 1024 && pc->buffer) {
@@ -445,6 +464,7 @@ static int idescsi_end_request (ide_drive_t *drive, int uptodate, int nrsecs)
hexdump(scsi_buf, min_t(unsigned, 16, pc->scsi_cmd->request_bufflen));
} else printk("\n");
}
+#endif
}
host = pc->scsi_cmd->device->host;
spin_lock_irqsave(host->host_lock, flags);
@@ -639,19 +659,14 @@ static int idescsi_map_sg(ide_drive_t *drive, idescsi_pc_t *pc)
return 1;
sg = hwif->sg_table;
- scsi_sg = pc->scsi_cmd->request_buffer;
- segments = pc->scsi_cmd->use_sg;
+ scsi_sg = scsi_sglist(pc->scsi_cmd);
+ segments = scsi_sg_count(pc->scsi_cmd);
if (segments > hwif->sg_max_nents)
return 1;
- if (!segments) {
- hwif->sg_nents = 1;
- sg_init_one(sg, pc->scsi_cmd->request_buffer, pc->request_transfer);
- } else {
- hwif->sg_nents = segments;
- memcpy(sg, scsi_sg, sizeof(*sg) * segments);
- }
+ hwif->sg_nents = segments;
+ memcpy(sg, scsi_sg, sizeof(*sg) * segments);
return 0;
}
@@ -907,15 +922,10 @@ static int idescsi_queue (struct scsi_cmnd *cmd,
pc->flags = 0;
pc->rq = rq;
memcpy (pc->c, cmd->cmnd, cmd->cmd_len);
- if (cmd->use_sg) {
- pc->buffer = NULL;
- pc->sg = cmd->request_buffer;
- } else {
- pc->buffer = cmd->request_buffer;
- pc->sg = NULL;
- }
+ pc->buffer = NULL;
+ pc->sg = scsi_sglist(cmd);
pc->b_count = 0;
- pc->request_transfer = pc->buffer_size = cmd->request_bufflen;
+ pc->request_transfer = pc->buffer_size = scsi_bufflen(cmd);
pc->scsi_cmd = cmd;
pc->done = done;
pc->timeout = jiffies + cmd->timeout_per_command;
--
1.5.2.2.249.g45fd
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] Is it time to kill ide-scsi.c?
2007-07-04 15:29 [PATCH] Is it time to kill ide-scsi.c? Boaz Harrosh
@ 2007-07-05 23:50 ` Jeff Garzik
2007-07-08 12:39 ` Boaz Harrosh
0 siblings, 1 reply; 3+ messages in thread
From: Jeff Garzik @ 2007-07-05 23:50 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: James Bottomley, Andrew Morton, linux-scsi, FUJITA Tomonori
Boaz Harrosh wrote:
> I have attempted (below) to convert ide-scsi to the new data
> accessors and cleanup the !use_sg code paths. Inspecting
> the code I can see places that still assume scsi_cmnd->request_buffer
> is a linear char pointer. Though I admit this assumption is hidden
> behind a flag "test_bit(PC_TRANSFORM, &pc->flags)". Is this an indication
> that this drivers no longer works? What is needed in order to kill this
> driver? If no killing is done than please accepted below patch.
>
> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
> ---
> drivers/scsi/ide-scsi.c | 48 ++++++++++++++++++++++++++++------------------
> 1 files changed, 29 insertions(+), 19 deletions(-)
This is a very popular driver for some configurations. I know many
people that used this for their ATAPI driver, rather than
ide-{cdrom,floppy,...}
Jeff
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Is it time to kill ide-scsi.c?
2007-07-05 23:50 ` Jeff Garzik
@ 2007-07-08 12:39 ` Boaz Harrosh
0 siblings, 0 replies; 3+ messages in thread
From: Boaz Harrosh @ 2007-07-08 12:39 UTC (permalink / raw)
To: Jeff Garzik; +Cc: James Bottomley, Andrew Morton, linux-scsi, FUJITA Tomonori
Jeff Garzik wrote:
> Boaz Harrosh wrote:
>> I have attempted (below) to convert ide-scsi to the new data
>> accessors and cleanup the !use_sg code paths. Inspecting
>> the code I can see places that still assume scsi_cmnd->request_buffer
>> is a linear char pointer. Though I admit this assumption is hidden
>> behind a flag "test_bit(PC_TRANSFORM, &pc->flags)". Is this an indication
>> that this drivers no longer works? What is needed in order to kill this
>> driver? If no killing is done than please accepted below patch.
>>
>> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
>> ---
>> drivers/scsi/ide-scsi.c | 48 ++++++++++++++++++++++++++++------------------
>> 1 files changed, 29 insertions(+), 19 deletions(-)
>
> This is a very popular driver for some configurations. I know many
> people that used this for their ATAPI driver, rather than
> ide-{cdrom,floppy,...}
>
> Jeff
>
>
>
Two questions than
1. All these users, don't they have a new solution with PATA drivers
or that is only for new HW/chipsets?
2. Do you know who is the maintainer of this driver? Because if it is
still needed, than my patch must be accepted. And I think my added BUG()
only does it good.
Thanks
Boaz
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-07-08 12:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-04 15:29 [PATCH] Is it time to kill ide-scsi.c? Boaz Harrosh
2007-07-05 23:50 ` Jeff Garzik
2007-07-08 12:39 ` Boaz Harrosh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).