On Tue, Sep 25, 2007 at 07:37:33AM -0600, Matthew Wilcox wrote:
> 2. Thanks to a thinko, we also discussed the upper-layer ->done. We think
> it should be feasible to move this from the scsi_cmnd to the scsi_device
> since sg doesn't use it.
I suspect putting it into the scsi_driver would be even better.
> 3. We also discussed scsi_pointer. It's really quite crufty, and it
> gets recycled for storing all kinds of things. The ambitious plan here
> is to change the whole way scsi_cmnds are allocated. Code is clearer
> than my description ...
>
> sym2.c:
>
> struct sym2_cmnd {
> struct scsi_cmnd cmd;
> int Phase;
> char *data_in;
> }
>
> struct scsi_host_template sym2_template {
> .cmnd_size = sizeof(sym2_cmnd);
> }
I'd prefer to add alloc_mnd and destroy_cmnd methods as per struct
inode. That also allows drivers to do things like dma_pool allocations
ahead of time and not worry about needing to do this kind of allocations
from softirq context which is at least theoretically deadlockable
without emergency pool schemes.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
