James Bottomley wrote: > On Tue, 2006-03-28 at 16:38 -0600, Brian King wrote: >> My direction at this point has been to move away from >> the virtual scsi host device for SATA devices attached >> to SAS HBAs. This seemed to me to be the clearest implementation. >> Then you have 1 SAS HBA = 1 struct scsi_host, no matter >> how many SATA devices are attached underneath it either >> via direct attach or via an expander. > > That's what a transport class implementation would allow you to do. As > long as the representation of the host controller device (be it PCI, > SCSI IDE or whatever) has an embedded generic device, the class can > attach and carry attributes. I'm still struggling a little with where you want to head here. Are you proposing a scsi_transport_sata in addition to the existing scsi transports, or are you proposing adding to the existing scsi_transport_sas code? I assume it is the latter, since a single SAS HBA will be supporting both SAS and SATA devices at the same time and currently scsi core only handles a single transport per scsi_host. 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
