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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html