>
> I took a quick look. Let me say to start, that it is really gross
> to be attempting to put together a phony Scsi_Device and Scsi_Cmnd, just
> so that you can queue a command to the host adapter itself. I would like
> it if there were another way of accomplishing the same thing without
> getting the mid-layer into the mix. If there were a general need for
> queueing commands to the SCSI ID for the HA itself, then I could
> incorporate something, but as far as I can see gdth is the only driver
> doing this.
>
> Anyways, the quick fix for your case is probably to add a couple
> of quick calls along the lines of:
>
> blk_init_queue(&SDpnt->request_queue, scsi_request_fn);
> SDpnt->request_queue.queuedata = (void *) SDpnt;
>
> initialize_merge_fn(SDpnt);
>
> If you go the quick fix route, PLEASE add a fixme comment to clean
> this up at a later date. Once you are done with the command, you should
> call:
>
> blk_cleanup_queue(&SDpnt->request_queue);
>
> At the moment this doesn't do that much, but at some point in the future
> it might do more, and you might as well add it for correctness.
>
> As long as you are at it, I am slowly in the process of
> eliminating scsi_init_malloc/scsi_init_free. These calls can be replaced
> with either kmalloc()/kfree(), or with __get_free_pages()/free_pages(). It
> depends upon whether you are allocating a multiple of a page size or not.
> The only tricky thing is that scsi_init_malloc does memset the memory to
> 0, so you would need to check and see if you need to do this. Anyways,
> gdth.c uses these interfaces, and it was kind of low on my list of things
> to do to fix this as well.
Does anybody from ICP vortex work on this driver or Linux support for GDT
adapters is already adandoned by their manufacturers?
===========================================================================
Sergey Kubushin aka the Tamer < > The impossible we do immediately.
e-mail: ksi@ksi-linux.com SK320-RIPE < > Miracles require 24-hour notice.
===========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/