Hi, >>> In order to support SCSI command emulation I had to update / >>> patch up the existing SCSI disk support. This might be >>> not to everyones taste, so I'm open to alternative >>> suggestions. >>> >>> But I certainly do _not_ want to update the SCSI disk >>> emulation, as this is really quite tied to the SCSI parallel >>> interface used by the old lsi53c895a.c. >> >> --verbose please. I'd prefer to fix scsi-disk bugs and/or limitations >> instead of working around them. >> > The problem is I don't have any documentation for the LSI parallel > SCSI controller. So I don't know if and in what shape I/O is passed > down, nor anything else. [ after briefly checking the code ] Hmm. Data is passed back+forth between scsi-device and scsi-adapter using a bounce buffer per request and a amazing maze of callbacks ... That interface needs some serious rework, so we have a chance to kill the memcpy() and use iovecs. > And as the SCSI disk emulation is really > tied into the LSI parallel SCSI controller, any change in the former > is likely to break the latter. Not really. > And what with me no way of fixing it. Hence I decided on this approach. From a really quick view fixing up the data xfer code paths doesn't look too bad. Think I'll give it a try. >>> Plus it doesn't do scatter-gather list handling, >> >> Which should be fixed anyway. >> > Quite. But as I said, the LSI parallel SCSI controller is going to > suffer. Don't think so. Even if scsi-disk *supports* scatter lists, lsi isn't forced to actually use that. I think we'll need a bounce-buffer mode anyway for usb-msd because it streams the scsi data in tons of small packets over usb ... cheers, Gerd _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization