Re: [PATCH] libata: rewrite SCSI host scheme to be one per ATA host

[Jeff Garzik <jeff@garzik.org>]

Grant Grundler wrote:
> On Wed, Apr 22, 2009 at 2:09 AM, Jeff Garzik <jeff@garzik.org> wrote:
>> Currently, libata creates a Scsi_Host per port.  This was originally
>> done to leverage SCSI's infrastructure to arbitrate among master/slave
>> devices, but is not needed for most modern SATA controllers.   And I
>> _think_ it is not needed for master/slave if done properly, either.
>>
>> The patch below converts libata such that there is now a 1:1
>> correspondence between struct Scsi_Host and struct ata_host.  ATA ports
>> are represented as SCSI layer 'channels', which is more natural.
> 
> Jeff,
> So far in reading this, the only reasons I gather for changing this
> mapping are "not needed" and "is more natural". Data Center
> environments (not just Google's) like to track disks in many different
> ways, including the SCSI identifiers since this one "key" for physical
> location. Breaking the current mappings is going to cause some people
> a world of pain since they will need to manually build (and integrate)
> old->new maps of the SCSI identifiers. Can you propose some real,
> tangible benefit to making this change? (e.g. enables some other
> feature)

Sure there are compat issues, just like there are compat issues with the 
existing consensus goal of moving libata to the block layer -- part of 
which implies that ATA disks would be served via a "native" block device 
rather than drivers/scsi/sd.c.

So at least to me, it is axiomatic that these issues will be examined.

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

"more natural" also solves a longstanding user confusion/complaint about 
libata:  users expected that libata would export each ATA "channel" 
(bus) as a SCSI channel.


> Mark already pointed out this might cause issues with Error Handling
> (forcing a review of all that code). So before triggering other
> developers (e.g. HW vendors) do that kind of work I'd like to hear
> what the reward is going to be at the end.

Are you aware that EH is already receiving a stream of updates, moving 
it from SCSI to the block layer?  This area has been in constant motion 
since, well, Tejun arrived and started improving things!  :)

	Jeff