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

[Grant Grundler]

On Thu, Apr 23, 2009 at 4:00 AM, Jeff Garzik <jeff@xxxxxxxxxx> wrote:
...
> 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.

agree

>
> 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.


> "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.

I haven't seen that complaint. And I'd be impressed by any "normal users" that
know the difference between "host" and "channel". This sounds like a developer
complaint to me. AFAICT, users just accepted the initial mapping.

If the mapping is going to change, it makes sense to address
outstanding complaints.
But it'd be helpful to attribute the complaint/problem report to a real person
and which HW they saw the issue on.

>> 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! Â:)

Yes, I have been following (and in generally very impressed with) Tejun's work.
I've read through about 1/2 of his patches. I clearly don't understand the
libata/SCSI subsystems as well he does.

But Tejun isn't the only person working on SATA drivers. AFAICT, the HW vendors
are doing most of the work to support new SAS/SATA controllers. I'm
thinking of Marvell,
Intel, LSI, and Broadcom off the top of my head.   I'm sure there are others
(Silicon Image?). Having a moving target will just make it harder for them
to focus on their core business (building/supporting controllers)
instead of trying
to keep up with kernel.org. I think has historically been a bigger problem.

thanks,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/