On Thu, 2009-04-23 at 10:59 -0700, Grant Grundler wrote: > > As to benefits, the phrase "more natural" means the code naturally aligns > > with existing object topologies (ata_host becomes analagous to Scsi_Host), > > which always has a long list of technical benefits. > > > > - we get to remove all the ugly hacks currently in place that assume > > ata_port is _the_ first class object. > > - we get to remove all the workarounds where SCSI assumes it manipulates all > > devices on a controller (not true in current libata) > > - SCSI (soon block) host-wide busy, block etc functionality now works as > > expected > > - it makes the libata conversion from SCSI to block layer easier > > - it makes integration with SAS+SATA devices such as mvsas or ipr easier > > - the list goes on; that is just off the top of my head, before my morning > > Mountain Dew > > Your initial list is good. In particular the issue around "SCSI Host-wide busy" > working as expected. Of all the things listed, this is the only one that *I* can > clearly identify as a user visible functional change. > > I'm not familiar with the the "workarounds where SCSI assumes it manipulates > all devices on a controller" issue. The few SATA controllers I've looked at can > deal with each port independently - e.g. discovery and phy reset. Anyway, this > seems to be closely tied with "SCSI Host-wide Busy". > > One reason I was thinking of NOT list above: "wide port" in SAS 2.0 controllers. > aka "port aggregation". E.g. http://www.pmc-sierra.com/products/details/pm8005/ > > To change port aggregation on the fly requires the SCSI host controller to be > manageable object. This should be a change in transport and not a change > in devices available....and there are some other problems with implementing > this but this is the main one I initially see. This isn't really a correct assessment. Wide ports are a SAS only problem. So sas has phys and ports ... and it's the port (essentially a virtual object) that communicates in the link diagram. A wide port has two or more phys in it. You can see the handling of this in libsas and the sas transport class today, but it's all handled in a fashion completely invisible to the SCSI mid layer ... it's an inessential abstraction, if you will. James -- 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
