James Bottomley wrote:
Well, no, not scsi transport; I think just a general transport ... see the raid_class for an example of one of these (albeit not very related to what you want to do, I'm afraid). technically, you can have multiple transports per device, even with SCSI ones. It's just convenient to simplify the single attachement case since that's the predominant one. The key is in the match function. Given a generic device, you have to know how to verify its a device of the type you want.
From what I understand, it looks like I should be creating a sata_class transport of sorts, which would attach to scsi_hosts that support SATA and would contain SATA host related attributes. It would also provide APIs such as sata_dev_alloc, sata_dev_add, similar to sas_phy_alloc, and sas_phy_add, which would be called by external users to attach SATA devices to the upper layers. sata_dev_add would result in the device getting hooked into libata and getting added to scsi core, etc. There could then also be per-device hooks/attributes in the sata_class transport as appropriate. However, since scsi core is the one that checks max_cmd_len, scsi core would somehow need to be able to poke into the sata host transport attribute to decide whether or not to accept the command. Probably an addition to struct scsi_transport_template? This is quite a change from the patchset I have been carrying for the past 5 months or so to add SATA support to ipr. The current ipr patch to add this support can be found here: http://marc.theaimsgroup.com/?l=linux-scsi&m=114263741229458&w=2 It requires no change to scsi core other than the patch we are discussing (which could technically also be done in libata), and requires minimal libata changes. I'm happy to start coding up a sata_class, but is there any chance of this being a phase 2 solution, and for the interim we proceed with something closer to what I have been submitting to the list for the past 5 months? I'm happy to drop the patch that started this thread if that helps. Would you be OK with the ipr patch in the URL above as an interim solution? Thanks, Brian -- Brian King eServer Storage I/O IBM Linux Technology Center - : 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
